1. Don't put your resume ahead ofthe requirements by Nitin Borwankar

【需求先于履歷】

身為架構師要平衡客戶、公司和個人的利益。用時興的技術為個人履歷增光添彩固然重要，但應該把客戶的長遠需求放在首位。約束技術偏好，能夠使客戶、團隊、自己和家人都多些快樂。在未來的工作中，客戶的口碑是比個人的履歷更加寶貴的東西。

2. Simplify essential complexity;diminish accidental complexity by NealFord

【簡化先天復雜性，避免后天復雜性】

任何業務問題都有其復雜性，簡化復雜性是客觀需要。但為此采取的工作很可能帶來新的復雜性。了解代碼中真正用于處理業務的比例，從實踐中發展出恰當的系統框架，避免隨意添加框架。后天復雜性的積累會使系統越來越難以維護和升級。

3. Chances are your biggest problemisn't technical by Mark Ramm

【技術不是最大問題】

聰明的架構師能夠選擇最恰當的技術，而有效的架構師則還要說服開發人員理解他的選擇。軟件是由人開發的，人心不齊才是最大的問題。有時人的問題導致項目失敗，卻讓技術來背黑鍋。必要時應進行平等的對話、理性的分析、耐心的解釋。

4. Communication is King; Clarityand Leadership its humble servants byMark Richards

【溝通為王，澄清和引領為仆】

閉門造車、發號施令的架構師必將被反抗的開發者所推翻。架構師應就項目的宗旨和目標與開發人員溝通。有效溝通的要點是簡明和垂范。拋開長篇大論的Word文檔，使用清晰易懂的Visio圖形;討論時使用白板，對重要的內容拍照記錄。與QA、PM和開發人員密切合作，讓他們了解架構過程，洞悉架構全景，引領他們走出迷茫。

5. Architecting is aboutbalancing by Randy Stafford

【在平衡中進行架構】

架構工作包括模塊劃分、接口定義、職責分配、模式應用、性能優化等傳統技術活動，也要考慮安全、可用性、支持、發布、開發條件等問題，更要照顧管理人員、操作人員、維護人員等有關各方的關切。要在平衡各方關切的過程中開展架構工作。

6. Seek the value in requestedcapabilities by Einar Landre

【鑒別客戶要求中的價值】

客戶往往把他們的思考作為解決他們所面臨的問題的方案。但客戶要求未必都是對解決實際問題有價值的。架構師應當提出更好、更節約的解決方案。這一目標可以通過和客戶進行討論達到。和客戶討論時，多從業務角度問問為什么，少使用軟件術語，不要假定客戶具有軟件方面的知識。

7. Stand Up! by Udi Dahan

【站著說話】

架構師和項目組成員的溝通，不應象過去和機器打交道一樣隨意。當你的聽眾超過一個人時，自己就應當站著說話。站著說話的好處是有指揮整個房間的氣勢，增加了你的權威和自信，別人更不容易打斷你的話。站著說話還能使用眼神交流、肢體語言，也有助于控制聲音。站著說話，能提高溝通效果。

8. Skyscrapers aren't scalable byMicheal Nygard

【摩天大樓不可伸縮】

把軟件工程比喻成蓋樓，有好的一面。從荒蕪的工地到聳立的高樓，過程漫長。每一段時間中，每一個工人都要各盡其責，每一個未完工的構件都要穩穩當當才行，值得軟件工程學習，這就是一次一個組件的增量部署。這個比喻也有不恰當的一面。摩天大樓在造成以后就不可搬遷、不可加層。而軟件則可以反復調整，這就是“及早發布”(Early release)。

9. You're negotiating more oftenthan you think. by Michael Nygard

【談判多過你的想象】

我們作為工程師，更愿意與人協作。而項目負責人作為控制項目成本的人，更在乎削減成本。我們看到的是談話，他看到的是談判，所以我們常常遭受預算打擊。如果你提了冗余、備份之類的東西后，他問你“這個東西必須要有嗎?”,千萬不要讓步。不要說“沒有也行，只是會在故障恢復期間不能運行”這樣的話。反而要說：“事實上不僅要兩套，要四套才能確保萬無一失。沒有這個，每天就至少會有三次出問題，而且不排除當你正在給董事長做演示的時候出問題。”

10. Quantify by Keith Braithwaite

【量化】

需求必須量化。“快”、“好”、”伸縮性”、“可用性”、“靈活”、“極少”、“大量”等都不是需求，因為它們不可量化，這些詞找不到客觀的衡量標準。談需求的時候，必須說明數目、時間、來源、去向，不能準確給出數值的，必須指明一個具體的范圍。例如：最大響應時間1500毫秒，平均響應時間為750至1250毫秒。

11. One line of working code isworth 500 of specification by Allison Randal

【一行正確代碼勝過千言萬語】

設計說明是宏觀描述，代碼則是微觀實現。可是如果設計說明脫離了編碼實現，猶如違背物理學原理的大樓設計，縱使它美輪美奐，也會轉眼間土崩瓦解。架構師做設計時，要時刻想著編碼人員如何實現它。設計完成后，如果程序員提出質疑，往往就是設計有問題，至少是設計不清晰。對設計進行再修改是正常的事情。

12. There is no one-size-fits-allsolution by Randy Stafford

【沒有通用解決方案】

一雙鞋難合千人腳，過去積累的經驗未必適合現在具體的應用情景，架構師要堅持鍛煉自己的情景意識，按照新的情景進行設計。想要打造一個通用的解決方案往往造成過度設計，添加大量無關宏旨、甚至影響性能的不合理要求。

13. It's never too early to thinkabout performance by Rebecca Parsons

【盡早考慮性能】

用戶通常只會提出功能需求。架構師要盡早考慮非功能需求。性能測試也要及早展開。

14. 14.Application architecturedetermines application performance byRandy Stafford

【軟件系統架構決定性能】

如果架構不良，性能就不會良好。資源不是無限的，動用再多的性能調優手段，到頭來也是束手無策。

15. Commit-and-run is a crime. by Niclas Nilsson

【帶錯提交是禍害】

下班時間到了才寫完最后一行代碼，干脆省略了編譯、測試的過程，直接提交代碼，迅速奔赴約會。這種做法使得隱藏的錯誤隨著項目組其他開發人員更新代碼而擴散，導致其他人不敢更新代碼，打亂了大家的工作流程。個別開發人員把自己該做的工作留給他人是錯誤的。當然，架構師也應考慮給開發人員創造好有利的環境。比如，自動構建工具、自動測試工具、測試驅動開發實踐、持續集成服務器等。

16. There Can be More than One by Keith Braithwaite

【世界并非千篇一律】

技術上能做到強求統一，實現一套數據模型、一種消息格式、一套收發系統，如此等等。可是業務世界往往是不一致、多側面、甚至模糊的。統一的設計未必能滿足各種業務要求，應當要允許那些互相矛盾、重復或交叉的非功能特性存在。

17. Business Drives by Dave Muirhead

【業務決定技術】

為了建設一個系統，架構師必須把技術部門和業務部門團結在一起。但要明白二者的立場是不同的，避免技術人員作出業務決策。建造系統通常都是講求投資回報的，從開工到投產要不斷遇到各種技術上的決策，要一直以滿足業務部門的要求為準則，才能獲得最大的投資回報。如果業務部門對技術部門的提問遲遲不予答復，那么可以視為委托開發團隊考慮。即使這樣也不能直接將問題交回給技術人員，因為業務問題是宏觀問題，技術決策是微觀問題。架構師應當組織討論并拿出答案。

18. Simplicity before generality,use before reuse by Kevlin Henney

【先簡化再泛化、先使用再重用】

用戶掏錢買的往往不是什么通用的功能，大多數時候他們只看重其中自認為重要的部分。設計的產品要先滿足具體的要求，經過實踐并簡化掉那些不必要的東西，才能進行泛化推廣;要先有使用的機會，才能帶來重用的機會。如果一開始就以通用、重用為目的閉門造車，結果很可能是無用、難用、棄用。

19. Architects must be handson by John Davies

【架構師必須是注重實踐】

架構師不是空談家，他必須在數據庫、軟件編程、數據信息、網絡等某一領域有專長并且通曉其它領域，換句話說，他要想帶領團隊就必須知道團隊成員需要知道的技術。架構師和項目經理，好比飛機上的副駕駛和駕駛。飛機常常是副駕駛操縱，可是關鍵時刻得看駕駛的。項目經理忙于日常任務安排、資源調配，而架構師看似清閑，而在技術決策中要提出重要的意見，對保證項目的質量和按期交付起著很大的作用。

20. Continuously Integrate by Dave Bartlett

【持續集成】

過去軟件項目中提倡及早構建、及時發布，以便盡早發現風險、避免風險。隨著自動構建技術日趨成熟，現在已經能夠做到持續集成了。持續集成(CI)工具可以自動構建、測試，在完成時還能向外發送電郵或即時信息。

#p#

21. Avoid Scheduling Failures byNorman Carnovale

【避免延期】

人的工作能力是有限的。同樣的工期內要增加工作量，就難免延期。不增加工作量但是強求縮短工期反而常常導致延期。因為，趕工通常造成設計不良、缺陷數量上升、測試不足等問題，日后處理這些問題反而需要更多的時間。因此，碰到有人要求縮短工期，應堅決主張原定工期。確實必須縮短工期的，就要將部分非必需功能從開發任務中剔除，留待下一期開發中去處理。這是一個協商談判的過程，架構師要有一定的技巧才能處理好。

22. Architectural Tradeoffs by Mark Richards

【架構中的取舍】

沒有哪個系統能同時做到高性能、高可用、高安全、高通用。架構師要帶領同事和客戶開誠布公地溝通，先滿足重要的目標，再滿足次要的目標。

23. Database as a Fortress by DanChak

【數據庫即堡壘】

開發團隊的人員是流動的，用戶的人員也是來來往往的，但是架構師要保證有一個東西不變，那就是數據庫結構。從項目的第一天，就要抱著建造堡壘一樣的態度設計數據庫，使它能經歷時間流逝和需求微調的考驗。

24. Use uncertainty as adriver by Kevlin Henney

【以不確定為動力】

生活中人們期待有多種選擇，可如果自己設計軟件，卻往往喜歡省事，在幾個選項中只采用一個。如此一來，軟件對用戶就不那么平滑順手。一個設計是否良好，是用修改所需的成本來衡量的。當遇到技術上的選擇時，不要匆忙決定，要退一步想想有沒有不進行選擇的辦法?只在是非分明、條件明確的情況下才需要選擇。

25. Scope is the enemy ofsuccess by Dave Quick

【項目規模是成功的敵人】

架構師如果好大喜功，不切實際地擴充項目的范圍，在時間、人力、物力、功能、質量等級、交付難度、風險系數、約束條件等方面不斷加碼，使項目變大、變復雜，那么就是在促使項目走向失敗。當項目規模擴充時，失敗的可能性也在以更快的速度增加。以下是避免規模增長的幾個策略：

(1). 求真務實：真實的需求是什么(客戶的底線在哪里)?

(2). 各個擊破：這個項目不能再分解成幾個各自獨立的小項目嗎?

(3). 主次有別：哪些是重要而穩定的需求?哪些是次要而易變的需求?

(4). 及早發布：錯誤是不可完全避免的，早點讓用戶見到作品就是給自己留下改正錯誤的時間。

26. Reuse is about people andeducation, not just architecture byJeremy Meyer

【重用要靠受過教育的人員】

一個設計良好、漂亮、可重用的框架或者代碼庫，只能由了解它、會用它、相信它的人來使用。

(1). 了解：沒有人會去查找自己不知道的東西，只有在公司中將它的信息推送到開發人員和設計人員面前，他們才會了解它。

(2). 會用：一點便通的人很少，大多數人必須經過培訓才會使用它。

(3). 相信：新來的人往往瞧不起舊的東西，他們傾向于通過重頭編寫來證明自己的才能，要設法讓他們相信重用成熟穩定的組件框架勝過自己編寫。

27. There is no 'I' inarchitecture by Dave Quick

【架構中沒有“我”字】

不成熟的架構師愛犯的毛病是：以為自己比客戶懂需求;把開發人員看作實現自己主張的資源;聽不進和自己不同的意見。

以下認識有助于架構師的成長：

(1). 不是架構師決定架構，是完整準確的需求決定架構，因此要密切接觸客戶進行需求分析。

(2). 架構不是架構師一個人的，是整個團隊的，架構師需要隊員遠勝于隊員需要架構師，因此要從心底尊重他們、團結他們。

(3). 模型不算是架構，只有能用的模型才是架構，因此要和組員一起進行演練以便檢查確認模型能支撐需求。

(4). 自我肯定、自我保護是人的天性，遇到壓力便表現出來，因此要每天花幾分鐘審視自己：是否對他人表達了應有的敬意和謝意?是否冷淡了他人的善意?是否真的明白他人為何與自己意見不同?

28. Get the 1000ft view by Erik Doernenburg

【生成低空視圖】

要了解地面的情況，需要適當的高度。在30000英尺的高空只能看到大塊的輪廓，不能看到它的結構;在地面則迷失在身邊的細節里而失去整體感覺;在大約1000英尺的低空，剛好能看清楚地面的結構。類似地，要了解軟件系統的質量也要適當的距離。系統架構圖太宏觀，很多關系不清楚;源代碼又太微觀，關系太瑣碎;只有在類和方法這一級生成圖表，才能評估軟件的質量。

29. Try before choosing by Erik Doernenburg

【試了再選】

選擇哪一個框架?使用哪個代碼庫?架構師不能坐在象牙塔的頂端做出設計并頒布給開發人員使用。在做出技術選擇之前，他應該放低身段，找開發人員商量，讓他們對可選的幾種方案分別實現，再提出各自的建議，最后由架構師綜合分析決定使用哪一種方案。

30. Understand The BusinessDomain by Mark Richards

【了解業務領域】

軟件架構既要采用高超的技術，又要深刻地反映業務領域的特點，才能實現業務目標。比如，保險業適用面向服務的架構，金融業適用基于工作流的架構。了解業務的最高標準，就是能用業務語言和公司的老總級人物交流。業務領域的知識是不斷更新的，比如汽車保險業新出現的一種臨時停車保險，就是一種新的業務動向。能夠把握領域發展動向，就能未雨綢繆，當公司有需要時可以迅速提出解決方案。

31. Programming is an act ofdesign by Einar Landre

【編程是創意設計，不是照圖施工】

汽車廠要出一輛新汽車，必須經歷概念車創意設計、流水線生產這兩大階段。軟件編程中，主要的工作是都是創意設計，很少照本宣科的。既然大家都知道設計新車型、開發新藥物這樣的工作往往不能按時完成，也不能確保成功，那么我們也不要指望軟件編程可以精確預測。

32. Time changes everything by Philip Nelson

【時間改變一切】

隨著時間的流逝，當初各路高手所設計的高瞻遠矚、機關算盡的框架、模式、范例、算法，有的如過眼云煙般消散得無影無蹤了，有的則最終流傳下來。歷史帶給我們三個啟示：

(1). 堅持有價值的領域：如果我們熟悉的領域已經沒有價值，要勇于探索新的領域，即便早期的嘗試不成功，也要克服困難堅持下去，正確的領域總會有正確的方案，盡管它也許來得很晚。

(2). 簡單規則：克服我們自身把問題復雜化的傾向，讓方案保持簡單。想一想，那些復雜的東西，如今哪個還在呢?

(3). 珍惜舊東西：雖然過去的東西不完全適合于現在的情景，可是把經歷了時間考驗的東西修一修，不是也很有把握滿足新的需要嗎?

33. Give developers autonomy by Philip Nelson

【讓開發人員自治】

架構師的職責不是要對開發人員如何工作進行指點。架構師的責任是在開發人員致力于編制類和方法、進行單元測試、創建數據庫時，保證這些部分合在一起能正常運行。了解他們的痛處，做出對應的改進。測試困難嗎?那就改善接口并減少依賴。領域抽象性不夠或過度?那就澄清它。開發順序不清楚?做個計劃吧。開發人員使用API時總犯相同的錯誤?那要把API的設計調整得更簡單明白。人們真的理解設計嗎?和他們交流闡述吧。不確定哪些地方需要伸縮性嗎?去和客戶交流并了解他們的業務模型吧。總之，架構師要給開發人員創造一個工作環境，而不是干涉開發人員份內的工作。

34. Value stewardship overshowmanship by Barry Hawkins

【做管家，不做演員】

管家是為雇主精打細算的人，演員是為觀眾嘩眾取寵的人。

架構師提出的解決方案，關系到公司的人力、財力、物力和時間。公司把架構師職責授予一個人，他就要替公司平衡投入和產出比例。正如理財師要對客戶承諾收益率一樣，架構師也要時刻考慮公司的收益，而不能把項目當成自己顯擺的舞臺。

35. Warning, problems in mirror maybe larger than they appear by Dave Quick

【問題可能大于表象】

項目中出現問題，往往得不到重視，最后難于收拾。原因主要有：

對問題習以為常的溫水煮青蛙效應;

人們對新經歷、新知識的畏懼心理;

開發人員不以為然的樂觀主義傾向;

組員只關心個人目標不重視全局目標;

人都有盲點，尤其是對自己的缺點視而不見。

要克服以上不利因素，可以從這幾方面著手：

建立組織級別的風險管理機制;

不搞少數服從多數，要鼓勵悲觀論調并進行討論，進而提出中立的對策;

敞開心胸，不斷聽取客戶意見;

讓自己信任的人指出自己的盲點。

36. The title of software architecthas only lower-case 'a's; deal with it by Barry Hawkins

【軟件架構師是新興職業】

軟件架構師是一門新興的職業，可是它具有律師、醫生、建筑師一樣的精英特質。大家努力吧!

37. Software architecture hasethical consequences by Michael Nygard

【軟件架構也有倫理后果】

說到人權、身份盜用、惡意程序等等，人們知道軟件架構可以助人行善，也可以助人作惡。其實除了大是大非問題，平時很多地方都值得進行倫理思考。比如說，一個軟件好用則千萬個用戶都省事，一個軟件難用則千萬個用戶都麻煩，他們的輕松愉快或者垂頭喪氣不就取決于我們架構師嗎?為了他們長久的簡便，我們要承擔一時的幸苦。軟件影響太多的人了，不要設計違背倫理的軟件，哪怕一點點都不要做。

38. Everything will ultimatelyfail by Michael Nygard

【萬物皆會出錯】

硬件會出錯，所以用冗余來對付。

軟件會出錯，所以用監控軟件來對付。可是監控軟件也是軟件啊，所以錯誤還是不可避免。

網絡是由硬件和軟件組成的，所以網絡的錯誤就是難免的了。

怎么辦?我們不能拒絕錯誤，我們必須接受錯誤。承認萬物皆會出錯，接著設計出適當的失敗模式，才能讓我們的系統安全地出錯。例如，承認汽車是會撞車的，然后設計可壓縮的部件來吸收撞擊的能量，起到保護乘客的作用。在軟件系統中，如果不設計失敗模式，失敗偏偏就會讓你措手不及。

39. Context is King by Edward Garson

【情景為王】

情景為王，簡單性是它謙恭的仆人。所謂情景，指的是業務驅動力、新興技術和思想潮流。首先要敞開思路，關注情景中各種各樣的因素，給它們排出優先級，然后才能制定出簡單的解決方案。

40. It's all about performance by Craig L Russell

【處處都要考慮性能】

如果有一種車寬敞、舒適、省錢又環保，就一定賣得好嗎?非也。一輛牛車即使達到這樣的標準也未必有幾個人去買。原因就在于它速度太慢了。軟件設計也是一樣，功能重要，性能也一樣重要。性能不單單指系統響應時間，還包括用戶操作步數、用戶思考時間、用戶輸入時間等。性能還包括那些自動執行而不與人互動的部分，比如每日夜間處理任務。試想一下，如果一個每天夜間執行的任務到了第二天的夜間還沒執行完，將會帶來難以預料的后果。

#p#

41. Engineer in the whitespaces by Michael Nygard

【設計空白處】

架構圖通常由一些方塊表示互相依賴的系統，它們之間用箭頭連接，箭頭邊上寫著小小的幾個字，剩下的就是大片的空白。這空白處看似什么都沒有，可是在現實中，有網卡、入侵檢測系統、防火墻、消息隊列服務、數據格式轉換服務、通信設備，甚至可能穿越萬水千山。因此，在這個箭頭旁，還是要把一些重要問題考慮清楚：

(1). 調用方操作太過頻繁怎么辦?忽略、禮貌地拒絕或者竭力滿足?

(2). 如果響應超時則調用方怎么辦?重試、等待或視為接收方故障?

(3). 雙方收到的數據版本或者格式與期待的不一致時怎么辦?

(4). 兩方中的任何一方短暫消失會有什么影響?

舉個例子，假設有個箭頭寫的是“HTTP搭載的SOAP-XML”，它可能會有這樣的注釋：“期待每個HTTP請求包含一條查詢，每個HTTP響應發回一條查詢結果。每秒最多接受100次請求，在99.999%比例下請求響應時間小于250毫秒”。

42. Talk the Talk by Mark Richards

【入行說行話】

專業人士之間常用行話交流，而架構師最重要的行話就是架構模式。模式可以按照層次范圍劃分為四類：企業架構模式、應用架構模式、集成模式、設計模式。企業架構模式處理高層架構，設計模式處理組件內部的架構。常見的企業架構模式有事件驅動架構(EDA)、面向服務架構(SOA)、面向資源架構(ROA)以及管道架構(PA)。應用架構模式是企業架構內部應用或子系統架構的模式，例如J2EE中的會話面(Session Façade)、傳輸對象(Transfer Object)模式。集成模式是在應用、子系統、組件之間共享信息和功能的模式，比如文件共享、遠過程調用和各種消息收發模式。設計模式是最底層的模式，是架構師和開發人員交流的標準詞匯。還要了解反面模式(anti-patterns)，也就是那些反復出現、起負作用、需要避免的過程。常見的反面模式包括分析麻痹(Analysis Paralysis)、委員會設計(Design By Committee)、蘑菇房管理(Mushroom Management)、死亡征途(Death March)等。了解架構模式何以讓我們更清楚、簡潔、高效地溝通，所謂入行說行話(walk the walk and talk the talk)。

43. Heterogeneity Wins by Edward Garson

【異構取勝】

在分布式軟件系統中，通信協議已經發生了一個重要的演變，就是從二進制協議向文本協議轉變。文本協議，比如用于Web服務的XML/SOAP、表述性狀態轉移(REST)、原子資源(Atom)、可擴展消息傳遞及呈現協議(XMPP)，使得通信更為簡單靈活，系統的不同部分可以按照自己的需要選擇不同的編程語言，以便發揮最佳的效果。由此形成的異構系統，必將超越過去由單一語言主宰的系統。

44. Dwarves, Elves, Wizards, andKings by Evan Cofsky

【小矮人、精靈、巫師和國王】

RandyWaterhouse在《Cryptonomicon》中將他遇到的人分為四類，他們是：

小矮人(Dwarves)： 他們在黑暗的洞穴中辛勤勞動，制作出漂亮的物品。他們的手藝名揚四方，他們的力量改變著大地。

精靈(Elves)：他們溫文爾雅，終日創造美麗神奇的東西。他們天賦極高，能實現其他種族不可思議的東西。

巫師(wizards)：他們精通魔法，無比強大。

國王(Kings)： 他們是領袖，知道如何調遣其他角色。

架構師好比是國王，該熟悉各個角色，還要保證所設計的架構中具有這些角色的位置。只為個別角色設計架構，就只能吸引個別的角色，不能發揮大家的特長。一個好國王，會給大家樹立追求的愿景，會讓大家各司其責，共同學習，共同成長，實現目標。

45. Learn from Architects ofBuildings by Keith Braithwaite

【向建筑師學習】

“建筑是一種社會行為，是人類活動的物質場所。”—Spiro Kostof

(在建筑中要充分考慮人和社會的因素)

“良好的教育和豐富的心靈也許能造就偉大的頭腦，卻不能造就偉大的建筑。”—Frank Lloyd Wright

(不斷嘗試和改進才能接近完美)

“醫生出了錯可以將死人埋掉，建筑師出了錯只能讓客戶種爬藤遮丑。”—ibid

(避免設計錯誤很重要)

“建筑師堅信，不僅要做上帝身邊的助手，還應該伺機取得上帝的寶座。”—Karen Moyer

(要立志精通客戶的業務)

“在建筑中和在一切操作藝術中一樣，最后都要歸于操作。操作的結果應當就是良好的建筑。好建筑有三個條件：有用、牢固、愉悅。”—Henry Watton

(好東西不經要有用、耐用，還要賞心悅目啊)

"建筑師一定是雕塑家或畫家。如果他不是雕塑家或畫家，他只能做個建筑工。"—John Ruskin

(美很重要)

"聽起來有點矛盾、但它的確是一個重要的真理：沒有哪個建筑能達到無瑕疵的崇高。"—ibid

(好作品也帶有作者和時代的局限性)

46. Fight repetition by NiclasNilsson

【消除重復】

軟件開發中有兩條真理：抄襲是作惡;重復勞動降低開發速度。如果一個項目的軟件大量存在復制、粘貼、修改的工作方式，或者不同地方都在處理驗證、審核、日志、數據持久化之類的工作，那么就有嚴重的重復問題。消除重復是架構師的職責。完全順序書寫的代碼只適合于給計算機執行，良好的代碼是給人讀的，要讓人讀起來清楚、高效、輕松，那么就要消除重復性。使用恰當的框架(包括面向方面編程框架)、對功能進行再抽象等，都是消除重復的方法。

47. .Welcome to the Real World byGregor Hohpe

【走進現實世界】

工程師喜歡精確，01世界的軟件工程師尤其喜歡按部就班的順序處理，喜歡是非分明。可是現實世界卻是凌亂的。客戶下單之后很快又要取消，支票被拒付，信件丟失，付款延期，承諾落空。用戶不按要求輸入數據，不按規定步驟操作。分布式系統帶來了更多的不一致性：服務連不通，不發通知就改接口，沒有事務保證。現實就是這個樣子，早晚總會出問題，你得承認它。但也別太害怕。事件驅動編程、狀態機模式、錯誤重試等這些都是可以采用的技術。只是，在現實世界里，你要記住：星巴克咖啡店不適用兩階段提交。

48. Don't Control, but Observe byGregor Hohpe

【寧觀察、不控制】

過去的系統比較簡單而固定，在架構上是實現設計模型，按模型控制構建過程。但是，21世紀的軟件開發中，在松耦合的基礎上對軟件提出了隨著時間演化的柔性(flexible)要求，因此就不再能夠嚴格控制。針對這種情況，可以先不用設計靜態的結構，而是在演化中持續觀察，從觀察所得到的數據中抽象出當時的模型，按照規則對模型進行驗證，保證它沒有循環依賴、空接收通道的消息發送等問題。

49. Janus the Architect by DaveBartlett

【向雅努斯學習】

雅努斯(Janus)是羅馬神話中的門神，他有兩個頭顱，守衛著過去通向未來的大門。架構師要向雅努斯那樣，能傾聽客戶的訴求、分析他們的趨勢。他設計出來的架構既要滿足眼前的需要，又要適應即將到來的變革，經得起時間的考驗。

50. Architects focus is on theboundaries and interfaces by EinarLandre

【架構師關注邊界和接口】

處理復雜系統的基本策略是“分而治之、各個擊破”。架構師要將整個系統劃分成若干情景(Context)，各個情景有自己明確的邊界(Boundary)，情景之間有組織歸屬、功能使用或者技術依賴關系，這些關系通過接口來具體實現。關注邊界和接口的結果，是形成低耦合、高內聚的系統。

51. Challenge assumptions -especially your own by Timothy High

【不要想當然】

因為assume(想當然)=ass(蠢驢) +u(你)+me(我)，所以想當然會使你我與蠢驢為伍。

沒有事實依據的道聽途說未必正確，沒有事實依據的主觀臆斷往往是錯的。即使正確的結論，也因時勢的變遷而發生改變。所以，在架構設計中，但凡要在幾種選項之間做出取舍的地方(比如性能與可維護性、成本與上市時間等)，都要提供選擇的理由。理由不能只是簡單的論斷，要有考查的要素(比如技術條件、人員技能、政策環境等)及其事實依據，。

52. Record your rationale by Timothy High

【記錄你的理由】

在作出技術取舍的時候，都要提供選擇的理由。提供理由的方式是把它記錄下來。要說明做了什么決定、選擇了什么、拒絕了什么，為何選這種而不選那種。這些文檔可以讓開發人員理解架構設計的內在邏輯、讓客戶理解為何某些部分要求更加昂貴的硬件設備、讓將來條件改變以后對系統架構進行修改更容易。

53. Empower developers by Timothy High

【培養開發人員】

架構師要盡力培養開發人員。為他們提供足夠的設備、網絡、數據、資料。保證他們具有所需的技能，不足的就要安排培訓。開發人員除了能動手實踐，還要參與學術討論，所以如果有出差經費的要讓組員參加各種宣講或會議，沒有經費的也要加入技術性的郵件列表并參與本地的一些活動。平庸的團隊不可能做出大事情，要盡可能參加選擇開發人員的過程，尋找那些對技術好學上進并且善于與團隊合作的人。在和軟件設計的大目標不沖突的地方，要讓開發人員自主決策。制定編碼原則、編碼規范。保護開發人員免受不必要的文字工作、辦公室雜務等打攪。架構師雖然不是項目經理，但在軟件開發過程方面要積極參與管理，消除各種障礙。

54. It is all about the data by Paul W. Homer

【軟件都跟數據有關】

一般討論編碼的時候，都是站在面向指令的視角，講命令、函數、算法。可是要理解一個復雜的系統(比如UNIX操作系統)，就很難在成千上萬行代碼中理出頭緒。這時，如果我們關注代碼下面的數據(比如UNIX系統的文件、進程等)，就相對容易理解些了。形成這種對比的原因是代碼很龐雜，而數據則很簡潔。后者就是面向數據的視角。大多數問題的核心是數據問題。關注數據，能更容易地處理復雜系統問題。要在系統建設早期完整地設計數據結構，避免在系統建設過程中或投入運行后再來修改數據結構。數據結構修改將導致大量的代碼修改。

55. Control the data, not just thecode by Chad LaVigne

【控制數據，而不只是代碼】

只有由代碼自動構建程序的工具是不夠的。手工或者編寫腳本來修改數據庫、添加數據不僅效率低下，而且容易出錯。自動構建工具不僅要考慮代碼的變化，還要考慮數據結構的變化，它們是不可分割的一個整體。

56. Don't Stretch The ArchitectureMetaphors by David Ing

【不要讓比喻誤導他人】

在描述抽象或新的設計時，架構師喜歡使用比喻。可是，比喻容易讓人誤解。比如，“一個游艇一樣的系統”，言者可能指的是池子里的小船，而聽者理解的是橫跨太平洋的豪華游輪。又比如，“一個文件柜”，言者只是想表示內容是按字母排列的，而聽者卻想的是文件柜有六個面、上面還嵌入了一個鐘表。只在開始的時候使用比喻，然后要迅速轉入精確的描述，不能停留在比喻上。

57. Focus on Application Supportand Maintenance by Mncedisi Kasper

【關注應用支持與維護】

很多架構師出身于開發人員，因此他們過多地關注開發階段而很少關注軟件系統運行以后的支持和維護階段。其實，一個軟件系統的生命周期中，支持維護階段超過80%以上的時間比例。所以，設計之初，就要關注支持維護。要注意，支持人員和開發人員不同，他們沒有IDE工具，沒有復雜的測試工具，也不能隨意關閉和啟動生產系統。系統要給他們提供足夠的問題跟蹤、審核、分析手段。只有系統管理員滿意了，才會大家都滿意。

58. Prepare to pick two by Bill dehOra

【學會三選二】

著名的Brewer猜想說：對于現代分布式應用系統來說，數據一致性(Consistency)、系統可用性(Availability)、服務規模可分區性(Partitioning)三個目標(合稱CAP)不可同時滿足，最多只能選擇兩個。

59. Prefer principles, axioms andanalogies to opinion and taste byMichael Harmer

【多用原則、公理和民意，少用觀點和偏好】

架構師個人的觀點和偏好需要結合項目的實際情況進行仔細分析、充分論證，才能作為架構設計的依據。而原則、公理和民意，相對可以直接地作為架構設計的依據。所以，要提高架構水平和提高效率，可以多用原則、公理和民意，少用個人的觀點和偏好。

#p#

60. Start with a Walking Skeletonby Clint Shank

【從可行走的骨架開始】

軟件開發中，越早發現問題，修改的代價越小。因此，要及早將各個部分聯接起來，形成一套可行走的骨架，按照用戶需求的優先級，先驗證重要的需求。驗證一輪后，進行下一輪開發，調整骨架、補充肌體，實現生長，等待后續的驗證。通過這種迭代、演化的方式，保證項目向正確的方向前進。

61. Share your knowledge andexperiencesby Paul W. Homer

【分享你的知識和經驗】

軟件業是一個年輕的行業，每個人都需要學習和進步。和他人分享你的知識、經驗，讓我們大家都發揮出全部的潛力，讓這個行業的明天更加燦爛。

62. Make sure the simple stuff issimple by Chad LaVigne

【簡單事情簡單辦】

設計人員往往會炫耀自己的知識，對簡單的問題設計復雜的解決方案。復雜的方案往往走向延期、成本超支甚至失敗。把聰明才智留著對付真正復雜的問題吧，不要再把問題復雜化。今天的事情今天辦，也不要把今天的問題拖到明天，以為和明天的問題一起解決是什么智慧。要知道，處理了今天的問題，才能通過反饋引出明天的需求。

63. If you design it, you should beable to code it. by Mike Brown

【只設計自己會編碼的架構】

架構師總是想創造精巧而新潮的設計。可是這樣的設計對項目其實是有影響的。如果使用了一些自己沒有動手做過的框架或者模式，不僅不能準確地估計工作量，而且還帶來開發人員學習周期不明、新元素隱藏的問題不明、削弱開發人員對架構師的信任、給項目帶來不必要的風險等副作用。記住：架構師首先是開發人員。

64. The ROI variable by GeorgeMalamidis

【計算投資回報】

在軟件項目中的每一項決策，都可以視為是投資。投資是講求回報的，即便不是金錢上的回報，也要給項目干系人帶來某種可見的好處，比如降低缺陷。把投入的成本和預期的回報相比較，計算出回報率，才能合理地確定是否要做某件事。

65. Your system is legacy, designfor it. by Dave Anderson

【系統即遺產，需要精心設計】

一個系統即便最業務前衛、技術先進，對于下一任負責人來說，也是一份遺產。當今軟件的特點就是迅速淘汰。如果想自己的系統投入生產，存活哪怕只是幾個月，也得接受一個現實，那就是維護人員需要修修補補。這意味著：

清楚——各個組件和類的執行條理清楚;

可測——系統各部分的特性容易驗證;

正確——系統按設計或常規運行;

追溯——為不了解系統內部情況的人提供問題追溯信息，以便快速定位和修復缺陷。

要抱著為繼任者留下遺產的態度來設計系統。

66. If there is only one solution,get a second opinion by Timothy High

【只有一個對策時，請教他人吧】

軟件架構是在各種條件下對某個問題提出解決方案。如果只能想出一個對策，這個對策往往不是最佳的，因為很難用一個解決方案滿足所有條件，通常有個按照需求的優先級進行取舍的過程。只能想出一個對策，也許是因為自己缺乏經驗，或者自己的經驗不適于新的問題領域。比如，一個長期設計三層結構的客戶端-服務器應用的人，碰到的是瀏覽器-服務器領域的問題。去向其他處理過類似問題的人請教，才能獲得更好的意見。

67. Understand the impact of changeby Doug Crawford

【理解變化的影響】

好的架構師能把復雜度降到最低，并能設計出通用程度足以經受變化考驗的解決方案。所謂變化，表現為：功能需求變化、規模演變、系統接口修改、團隊人員進出等等。軟件項目中變化的廣度和復雜度是無法預測的，不能避免前進道路上所有的波折。但架構師應該識別出那些事關項目成敗的大波折。他不僅要管理變化，還要確保變化是可管理的。比如：一個高度分布的系統，對流程的變化是在所難免的，可是又要承載長期運行、有狀態的事務，那么就必須要設計成能同時支持新老版本的過程。

68. You have to understand Hardwaretoo by Kamal Wickramanayake

【必須了解硬件】

架構師不僅要關注軟件架構，也要關注硬件容量。硬件容量規劃是系統設計中的一個重要部分。如何準確地預測用戶數量及其變化趨勢，如何評估硬件的發展，都是做容量規劃的必備知識。

69. Shortcuts now are paid backwith interest later by Scot Mcphee

【現在節省的，將來加倍還】

在項目開發階段，可能會省略哪些不產生直接價值的工作，比如單元測試，又比如設計優化。現在節省了一點工作，將來系統進入維護階段以后，要改正隱藏的錯誤，要花幾倍的代價。

70. "Perfect" is theEnemy of "Good Enough" by Greg Nyberg

【優秀是良好的敵人】

作為軟件解決方案，做到良好就行了，不要為了追求優秀而過度設計。良好的東西，在功能性、可維護性、性能指標等方面都能滿足一般要求。如果過度追求優秀，可能突出了某一方面，而損害了其它方面，為系統的長期運行維護帶來不好的影響。

71. Avoid "Good Ideas"by Greg Nyberg

【別提“好點子”】

當項目在按部就班地前進的時候，大家都感覺良好。這時有人就會提出所謂的好點子。比如：

“如果在這里改動一下，就太酷了。”

“嗨，他們又發布那個框架的新版本了，我們得趕緊更新。”

“一邊開發新模塊，一邊重構老模塊。”

“這項技術太強大了，可以用在我們的項目上。”

“我幫你想了一下，發現一個好主意!”

這些好點子往往是項目殺手。一旦付諸實踐，對項目造成的改動不是當初想象的那么簡單。除了極個別之外，大部分會把項目慢慢地拖入深淵，有的甚至會讓項目迅速失敗。

72. Great content creates greatsystems by Zubin Wadia

【好內容成就好系統】

不管系統的需求分析、設計、開發、安全、維護做得多好，如果忽略了內容建設，則它都不會是一個好系統。對于那些以內容為基礎的系統來說，內容就是成功和失敗的分界線，FaceBook 對 Orkut， Google 對 Cuil，NetFlix 對 BlockbusterOnline，等等，都是以內容取勝的例子。評價內容時，考慮一下幾個條件：數量是否足夠?時間上是否及時?渠道上是否豐富(RSs、紙質表單、電子郵件等)?

73. The Business Vs. The AngryArchitect by Chad LaVigne

【業務人員與憤怒的架構師】

架構師是為業務人員服務的，要忍耐，不要和業務人員爭吵。如果你和他們分歧實在太大，那就只有換個自己覺得輕松的地方了。

74. Stretch key dimensions to seewhat breaks by Stephen Jones

【撐大關鍵維度，發現破綻】

系統各方面的處理能力是有一定的前提條件的。這些前提條件在實際運行中有可能發生變化。對于系統的關鍵維度，要進行驗證，看看如果運行負荷超出，哪些地方會被撐破。

75. Before anything, an architectis a developer by Mike Brown

【架構師首先是開發者】

架構設計要落實到開發工作。如果你設計它，你就要能夠編碼它。如果連你都不知道如何編碼，別指望別人能編碼。

76. A rose by any other name willend up as a cabbage by Sam Gardiner

【玫瑰不叫玫瑰，它就淪落到白菜的地位】

如果你不知道如何稱呼一個系統，你就不可能編寫它。如果你對一個系統三改其名，你最好先停下來想想到底要做什么，不要急于構建它。

77. Stable problems get highquality solutions by Sam Gardiner

【穩定的問題才有優質的解決方案】

現實世界的解決方案不是挑戰有難度的學術研究。設計現實的方案時，要把問題劃分為穩定、有限的小塊，再針對明確的小塊來進行解決。穩定的問題得到穩定的設計，穩定的設計得到優質的解決方案。

78. It Takes Diligence by BrianHart

【勤勉】

一招不慎，滿盤皆輸。架構師應當勤勉，認認真真做好每一項平凡的工作。

79. Take responsibility for yourdecisions by Yi Zhou

【對決策負責】

大約三分之二的項目是失敗的，表現有工期延誤、預算超支、用戶不滿等。失敗的重要原因是架構不當。通過以下幾條，可以做到對架構決策負責：

準備決策時，務必反復推敲;

進行決策時，務必決策有據(書面憑據);

做出決策后，做到定期自評;

有疑難問題，請教領域專家。

#p#

80. Don’t Be a Problem Solver by Eben Hewitt

【不做解題機】

作為一個架構師，要處理的問題是方方面面的。不要在開發人員一遇到編程問題就幫他們解答。很多問題往往他們自己可以查資料找到答案。幫助他們解答簡單的問題是放棄了處理更復雜問題的機會。

作為一個架構師，要知道解決問題的最好方式就是避免發生問題。不要對所有問題一概接收，要使用成熟好用工具，一開始就避免發生問題。沒有問題，比解決問題好。

81. Choose your weapons carefully,relinquish them reluctantly by Chad LaVigne

【在恰當的時候，鳥槍換炮】

架構師的武器庫中，有自己歷經大小戰役的各式武器。新武器紛紛出世，該換的時候就得換。但換武器也得考慮時機。

一要評估風險：新武器是否適用于眼前的項目?

二要評估成本：掌握新技術所花費的人力物力是否負擔得起?

三要評估形勢：看中的武器是曇花一現還是大勢所趨?

82. Your Customer is Not YourCustomer by Eben Hewitt

【客戶的客戶，才是我們的客戶】

當討論需求的時候，不要只顧著聽客戶的陳述。客戶也許不了解他的客戶想要什么。而找出他的客戶(系統的終端用戶)的真實需求，是系統成功的必要條件。所以說，客戶的客戶，才是我們的客戶。要關心客戶的客戶。

83. It will never look likethat by Peter Gillard-Moss

【系統不會是設計的模樣】

在一個永恒變化的世界中，設計是一個持續進行和經驗實證的過程。無論當初設計如何深入細致，系統永遠不會像設計的那樣變成現實。某些情況總會發生，某個外部因素總會影響系統，甚至內部某個人的代碼也會出現異常。或者設計依賴的某些信息出錯，或者推論不正確，或者混淆了某些概念的細微差別。也許需求變了，也許技術更新了，也許某人找到了比你更好的方法。這些微小的變化促使你修改設計，從一個版本到另一個版本，直到你不堪忍受。

84. Choose Frameworks that playwell with others by Eric Hawthorne

【選擇好搭配的框架】

在選擇框架的時候，不僅要看它是否在自己擅長的領域做得好，還要看它是否容易和其它框架搭配。對框架的要求是：謙虛、簡單、專業。所謂謙虛，是指不妄想包攬自己不擅長領域的工作，不和其它框架重疊。

85. Make a strong businesscase by Yi Zhou

【搞定一個強大的業務專案】

以下五步，助你做成一個強大的業務專案。

建立價值提議：你的新軟件架構有什么價值?和其它架構相比如何提高生產能力和效率?

制定量化指標：帶來的豐厚回報包括哪些合理的數據指標?

換成傳統標準：把這些數據指標換算成傳統的業務標準——金錢，它們是多少?

了解何處停手：向項目干系人了解，這項提議在哪些業務上應用以后，能夠適可而止?

尋找恰當時機：什么時候用戶比較能接受我們的提議?比如另一個架構慘遭失敗的時候。

86. Pattern Pathology by Chad LaVigne

【模式病】

模式是為了交流和理解而總結的設計方法。在設計上使用模式，要考慮實用、高效。如果為了炫耀自己關于模式的知識，在設計中塞入大量模式，那就犯了模式病。要以高效的解決方案為中心，只采用那些的確能解決問題的模式，避免犯模式病。

87. Learn a new language by Burk Hufnagel

【學習新語言】

要學習業務部門的業務語言，才能和他們有效溝通。

要學習編程人員的技術語言，才能和他們有效溝通。

88. Don't Be Clever by Eben Hewitt

【不要聰明要愚笨】

做人，尤其是做架構師，確實是需要有思想、有知識、有遠見。可是，我們設計的架構卻應該反過來，不要聰明，要愚笨。所謂愚笨，就是簡單，堅持一個組件只能在確定的條件下做一件事。聰明的組件造價高昂，維護艱難。愚笨的組件開發容易，維護簡單。聰明的架構在現實面前往往脆弱不堪，愚笨的架構卻生命長久。

89. Build Systems to be Zuhanden byKeith Braithwaite

【建造應手的系統】

應手(德文zuhanden)和在手(德文vorhanden)是哲學家海德格爾創造的概念。應手的東西是人在達成他的目標時隨手可用的工具，它近乎成為人身體的一部分而不需要關注，只需要使用。在手的東西是需要人時刻關注的工具，它要顯示自己的存在，要強調自己的權利，以致于主人因注意它而難于接近目標。我們建造系統的時候，容易把系統看得太重，建造出在手的系統。但一個真正好的系統，應該是應手的系統，對于用戶越透明越好。

90. Find and retain passionate problemsolvers by Chad LaVigne

【尋找和挽留有激情的問題解決者】

組建一支好的開發團隊，要靠出眾的開發人員。開發人員不僅要有豐富的知識，更要有解決問題的熱情和技能。選人的時候，不要太關注知識，而忽略了熱情和技能。

91. Software doesn’t really existby Chad LaVigne

【軟件無形】

軟件工程和傳統的土木工程比起來，具有產品無形的特點。無形意味著我們可以不按土木工程那樣的順序來建造，這是它的好處。可是，無形也有壞處。用戶容易產生誤解，以為軟件可以隨便修改、可以中途大幅度地變更需求。

92. Pay down your technical debtby Burk Hufnagel

【償還技術債務】

一個使用中的系統，總有一天會出現BUG或者要增加新特性。這時候有兩種相反的意見。客戶要求盡快解決，而開發人員卻要求慢慢設計、修改、測試。面對這樣的矛盾，架構師就會想，不如走條捷徑，把問題應付了事。但是，在技術問題上，沒有捷徑可走，該做的工作總要做。捷徑不僅有快的一面，也有臟的一面。把臟東西放到系統中，增加了系統的不穩定性，提高了將來運行維護的成本。第一次不做好，以后就要付出利息。所以，要看客戶的要求到底有多急迫，是否值得付出技術上的利息而做那種匆匆忙忙的發布。如果一定要盡快發布，也不要發布了就止步不前。要馬上投入新工作，提供良好技術解決方案，盡快償還欠下的債務。

93. You can't future-proofsolutions by Richard Monson-Haefel

【不能做面向未來的方案】

人不能預測未來是一條普遍的真理。未來不是十年二十年那么漫長的時間，未來就在這確定的一刻之后。周一活生生見面的人，周二卻傳來撞車的噩耗，這便是未來不確定的例證。今日選擇的語言會成為明日的COBOL，今日選擇的框架會成為明日的DCOM。要弄明白今日的需求已是不易，想知道明日的需求終歸徒勞。不如務實一些，就提供對今日需求的最佳解決方案吧。

94. The User Acceptance Problem byNorman Carnovale

【用戶接受問題】

人們往往難以接受一個新系統或者大升級。究其原因，有以下幾種：

(1) 有的人擔心新系統替代老系統后功能無法使用，自己失去影響和權力。

(2) 有的人害怕未經檢驗的新技術。

(3) 有的人擔心成本/預算。

(4) 有的人只是不喜歡變化。

針對不同的擔憂，用培訓、演示等方式與用戶分享新系統帶來的好處、新系統的局限，促進用戶接受新系統。

95. The Importance of Consommé by Eben Hewitt

【清湯的重要性】

美味的牛肉清湯需要精心制作，要剔除眾多雜質才能得到。據說有的烹飪學校的老師把十美分硬幣放在碗底進行檢驗，能透過湯看清硬幣上的日期的，才算好湯。軟件架構也需要反復提問、反復調整，需要去除各種雜質，直到只剩下簡單、可核實的關于系統真實特性的描述。

96. For the end-user, the interfaceis the system by Vinayak Hegde

【對于終端用戶，界面就是系統】

不管你的系統有多先進和與眾不同，如果它的用戶界面讓人痛苦，就等于系統讓人痛苦。有很多好系統被壞界面給遮蔽了。要把用戶界面當作軟件項目中的重要決策之一來對待。

97. Great software is not built, itis grown by Bill de hora

【偉大的軟件不是建造出來的，它是生長出來的】

雖然軟件要進行架構設計，也從建筑和工程中借鑒了很多比喻，可偉大的軟件不是建造出來的，它是生長出來的。一開始就建造龐大的軟件，很容易失敗。我們要有宏大的遠景，但是必須要在小處下手。先做一個小的系統，再慢慢演化升級，向心目中的遠景靠近。

原文鏈接：http://article.yeeyan.org/view/194678/203297

譯文鏈接：http://architect.97things.oreilly.com/wiki/index.php/97_Things_Every_Software_Architect_Should_Know_-_The_Book