成就職業(yè)理想：九十七條架構師必知的事情
51CTO 發(fā)表于：11年06月29日 10:16 [轉載] 51CTO
60. Start with a Walking Skeletonby Clint Shank
【從可行走的骨架開始】
軟件開發(fā)中，越早發(fā)現(xiàn)問題，修改的代價越小。因此，要及早將各個部分聯(lián)接起來，形成一套可行走的骨架，按照用戶需求的優(yōu)先級，先驗證重要的需求。驗證一輪后，進行下一輪開發(fā)，調整骨架、補充肌體，實現(xiàn)生長，等待后續(xù)的驗證。通過這種迭代、演化的方式，保證項目向正確的方向前進。
61. Share your knowledge andexperiencesby Paul W. Homer
【分享你的知識和經驗】
軟件業(yè)是一個年輕的行業(yè)，每個人都需要學習和進步。和他人分享你的知識、經驗，讓我們大家都發(fā)揮出全部的潛力，讓這個行業(yè)的明天更加燦爛。
62. Make sure the simple stuff issimple by Chad LaVigne
【簡單事情簡單辦】
設計人員往往會炫耀自己的知識，對簡單的問題設計復雜的解決方案。復雜的方案往往走向延期、成本超支甚至失敗。把聰明才智留著對付真正復雜的問題吧，不要再把問題復雜化。今天的事情今天辦，也不要把今天的問題拖到明天，以為和明天的問題一起解決是什么智慧。要知道，處理了今天的問題，才能通過反饋引出明天的需求。
63. If you design it, you should beable to code it. by Mike Brown
【只設計自己會編碼的架構】
架構師總是想創(chuàng)造精巧而新潮的設計。可是這樣的設計對項目其實是有影響的。如果使用了一些自己沒有動手做過的框架或者模式，不僅不能準確地估計工作量，而且還帶來開發(fā)人員學習周期不明、新元素隱藏的問題不明、削弱開發(fā)人員對架構師的信任、給項目帶來不必要的風險等副作用。記�。杭軜嫀熓紫仁情_發(fā)人員。
64. The ROI variable by GeorgeMalamidis
【計算投資回報】
在軟件項目中的每一項決策，都可以視為是投資。投資是講求回報的，即便不是金錢上的回報，也要給項目干系人帶來某種可見的好處，比如降低缺陷。把投入的成本和預期的回報相比較，計算出回報率，才能合理地確定是否要做某件事。
65. Your system is legacy, designfor it. by Dave Anderson
【系統(tǒng)即遺產，需要精心設計】
一個系統(tǒng)即便最業(yè)務前衛(wèi)、技術先進，對于下一任負責人來說，也是一份遺產。當今軟件的特點就是迅速淘汰。如果想自己的系統(tǒng)投入生產，存活哪怕只是幾個月，也得接受一個現(xiàn)實，那就是維護人員需要修修補補。這意味著：
清楚——各個組件和類的執(zhí)行條理清楚;
可測——系統(tǒng)各部分的特性容易驗證;
正確——系統(tǒng)按設計或常規(guī)運行;
追溯——為不了解系統(tǒng)內部情況的人提供問題追溯信息，以便快速定位和修復缺陷。
要抱著為繼任者留下遺產的態(tài)度來設計系統(tǒng)。
66. If there is only one solution,get a second opinion by Timothy High
【只有一個對策時，請教他人吧】
軟件架構是在各種條件下對某個問題提出解決方案。如果只能想出一個對策，這個對策往往不是最佳的，因為很難用一個解決方案滿足所有條件，通常有個按照需求的優(yōu)先級進行取舍的過程。只能想出一個對策，也許是因為自己缺乏經驗，或者自己的經驗不適于新的問題領域。比如，一個長期設計三層結構的客戶端-服務器應用的人，碰到的是瀏覽器-服務器領域的問題。去向其他處理過類似問題的人請教，才能獲得更好的意見。
67. Understand the impact of changeby Doug Crawford
【理解變化的影響】
好的架構師能把復雜度降到最低，并能設計出通用程度足以經受變化考驗的解決方案。所謂變化，表現(xiàn)為：功能需求變化、規(guī)模演變、系統(tǒng)接口修改、團隊人員進出等等。軟件項目中變化的廣度和復雜度是無法預測的，不能避免前進道路上所有的波折。但架構師應該識別出那些事關項目成敗的大波折。他不僅要管理變化，還要確保變化是可管理的。比如：一個高度分布的系統(tǒng)，對流程的變化是在所難免的，可是又要承載長期運行、有狀態(tài)的事務，那么就必須要設計成能同時支持新老版本的過程。
68. You have to understand Hardwaretoo by Kamal Wickramanayake
【必須了解硬件】
架構師不僅要關注軟件架構，也要關注硬件容量。硬件容量規(guī)劃是系統(tǒng)設計中的一個重要部分。如何準確地預測用戶數量及其變化趨勢，如何評估硬件的發(fā)展，都是做容量規(guī)劃的必備知識。
69. Shortcuts now are paid backwith interest later by Scot Mcphee
【現(xiàn)在節(jié)省的，將來加倍還】
在項目開發(fā)階段，可能會省略哪些不產生直接價值的工作，比如單元測試，又比如設計優(yōu)化。現(xiàn)在節(jié)省了一點工作，將來系統(tǒng)進入維護階段以后，要改正隱藏的錯誤，要花幾倍的代價。
70. "Perfect" is theEnemy of "Good Enough" by Greg Nyberg
【優(yōu)秀是良好的敵人】
作為軟件解決方案，做到良好就行了，不要為了追求優(yōu)秀而過度設計。良好的東西，在功能性、可維護性、性能指標等方面都能滿足一般要求。如果過度追求優(yōu)秀，可能突出了某一方面，而損害了其它方面，為系統(tǒng)的長期運行維護帶來不好的影響。
71. Avoid "Good Ideas"by Greg Nyberg
【別提“好點子”】
當項目在按部就班地前進的時候，大家都感覺良好。這時有人就會提出所謂的好點子。比如：
“如果在這里改動一下，就太酷了。”
“嗨，他們又發(fā)布那個框架的新版本了，我們得趕緊更新。”
“一邊開發(fā)新模塊，一邊重構老模塊。”
“這項技術太強大了，可以用在我們的項目上。”
“我?guī)湍阆肓艘幌拢l(fā)現(xiàn)一個好主意!”
這些好點子往往是項目殺手。一旦付諸實踐，對項目造成的改動不是當初想象的那么簡單。除了極個別之外，大部分會把項目慢慢地拖入深淵，有的甚至會讓項目迅速失敗。
72. Great content creates greatsystems by Zubin Wadia
【好內容成就好系統(tǒng)】
不管系統(tǒng)的需求分析、設計、開發(fā)、安全、維護做得多好，如果忽略了內容建設，則它都不會是一個好系統(tǒng)。對于那些以內容為基礎的系統(tǒng)來說，內容就是成功和失敗的分界線，F(xiàn)aceBook 對 Orkut， Google 對 Cuil，NetFlix 對 BlockbusterOnline，等等，都是以內容取勝的例子。評價內容時，考慮一下幾個條件：數量是否足夠?時間上是否及時?渠道上是否豐富 (RSs、紙質表單、電子郵件等)?
73. The Business Vs. The AngryArchitect by Chad LaVigne
【業(yè)務人員與憤怒的架構師】
架構師是為業(yè)務人員服務的，要忍耐，不要和業(yè)務人員爭吵。如果你和他們分歧實在太大，那就只有換個自己覺得輕松的地方了。
74. Stretch key dimensions to seewhat breaks by Stephen Jones
【撐大關鍵維度，發(fā)現(xiàn)破綻】
系統(tǒng)各方面的處理能力是有一定的前提條件的。這些前提條件在實際運行中有可能發(fā)生變化。對于系統(tǒng)的關鍵維度，要進行驗證，看看如果運行負荷超出，哪些地方會被撐破。
75. Before anything, an architectis a developer by Mike Brown
【架構師首先是開發(fā)者】
架構設計要落實到開發(fā)工作。如果你設計它，你就要能夠編碼它。如果連你都不知道如何編碼，別指望別人能編碼。
76. A rose by any other name willend up as a cabbage by Sam Gardiner
【玫瑰不叫玫瑰，它就淪落到白菜的地位】
如果你不知道如何稱呼一個系統(tǒng)，你就不可能編寫它。如果你對一個系統(tǒng)三改其名，你最好先停下來想想到底要做什么，不要急于構建它。
77. Stable problems get highquality solutions by Sam Gardiner
【穩(wěn)定的問題才有優(yōu)質的解決方案】
現(xiàn)實世界的解決方案不是挑戰(zhàn)有難度的學術研究。設計現(xiàn)實的方案時，要把問題劃分為穩(wěn)定、有限的小塊，再針對明確的小塊來進行解決。穩(wěn)定的問題得到穩(wěn)定的設計，穩(wěn)定的設計得到優(yōu)質的解決方案。
78. It Takes Diligence by BrianHart
【勤勉】
一招不慎，滿盤皆輸。架構師應當勤勉，認認真真做好每一項平凡的工作。
79. Take responsibility for yourdecisions by Yi Zhou
【對決策負責】
大約三分之二的項目是失敗的，表現(xiàn)有工期延誤、預算超支、用戶不滿等。失敗的重要原因是架構不當。通過以下幾條，可以做到對架構決策負責：
準備決策時，務必反復推敲;
進行決策時，務必決策有據(書面憑據);
做出決策后，做到定期自評;
有疑難問題，請教領域專家。
