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

【需求先于履歷】

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

2. Simplify essential complexity;diminish accidental complexity by NealFord

【簡化先天復(fù)雜性，避免后天復(fù)雜性】

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

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

【技術(shù)不是最大問題】

聰明的架構(gòu)師能夠選擇最恰當(dāng)?shù)募夹g(shù)，而有效的架構(gòu)師則還要說服開發(fā)人員理解他的選擇。軟件是由人開發(fā)的，人心不齊才是最大的問題。有時人的問題導(dǎo)致項目失敗，卻讓技術(shù)來背黑鍋。必要時應(yīng)進(jìn)行平等的對話、理性的分析、耐心的解釋。

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

【溝通為王，澄清和引領(lǐng)為仆】

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

5. Architecting is aboutbalancing by Randy Stafford

【在平衡中進(jìn)行架構(gòu)】

架構(gòu)工作包括模塊劃分、接口定義、職責(zé)分配、模式應(yīng)用、性能優(yōu)化等傳統(tǒng)技術(shù)活動，也要考慮安全、可用性、支持、發(fā)布、開發(fā)條件等問題，更要照顧管理人員、操作人員、維護(hù)人員等有關(guān)各方的關(guān)切。要在平衡各方關(guān)切的過程中開展架構(gòu)工作。

6. Seek the value in requestedcapabilities by Einar Landre

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

客戶往往把他們的思考作為解決他們所面臨的問題的方案。但客戶要求未必都是對解決實際問題有價值的。架構(gòu)師應(yīng)當(dāng)提出更好、更節(jié)約的解決方案。這一目標(biāo)可以通過和客戶進(jìn)行討論達(dá)到。和客戶討論時，多從業(yè)務(wù)角度問問為什么，少使用軟件術(shù)語，不要假定客戶具有軟件方面的知識。

7. Stand Up! by Udi Dahan

【站著說話】

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

8. Skyscrapers aren't scalable byMicheal Nygard

【摩天大樓不可伸縮】

把軟件工程比喻成蓋樓，有好的一面。從荒蕪的工地到聳立的高樓，過程漫長。每一段時間中，每一個工人都要各盡其責(zé)，每一個未完工的構(gòu)件都要穩(wěn)穩(wěn)當(dāng)當(dāng)才行，值得軟件工程學(xué)習(xí)，這就是一次一個組件的增量部署。這個比喻也有不恰當(dāng)?shù)囊幻妗Ｄμ齑髽窃谠斐梢院缶筒豢砂徇w、不可加層。而軟件則可以反復(fù)調(diào)整，這就是“及早發(fā)布”(Early release)。

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

【談判多過你的想象】

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

10. Quantify by Keith Braithwaite

【量化】

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

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

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

設(shè)計說明是宏觀描述，代碼則是微觀實現(xiàn)?？墒侨绻O(shè)計說明脫離了編碼實現(xiàn)，猶如違背物理學(xué)原理的大樓設(shè)計，縱使它美輪美奐，也會轉(zhuǎn)眼間土崩瓦解。架構(gòu)師做設(shè)計時，要時刻想著編碼人員如何實現(xiàn)它。設(shè)計完成后，如果程序員提出質(zhì)疑，往往就是設(shè)計有問題，至少是設(shè)計不清晰。對設(shè)計進(jìn)行再修改是正常的事情。

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

【沒有通用解決方案】

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

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

【盡早考慮性能】

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

14. 14.Application architecturedetermines application performance byRandy Stafford

【軟件系統(tǒng)架構(gòu)決定性能】

如果架構(gòu)不良，性能就不會良好。資源不是無限的，動用再多的性能調(diào)優(yōu)手段，到頭來也是束手無策。

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

【帶錯提交是禍害】

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

16. There Can be More than One by Keith Braithwaite

【世界并非千篇一律】

技術(shù)上能做到強(qiáng)求統(tǒng)一，實現(xiàn)一套數(shù)據(jù)模型、一種消息格式、一套收發(fā)系統(tǒng)，如此等等?？墒菢I(yè)務(wù)世界往往是不一致、多側(cè)面、甚至模糊的。統(tǒng)一的設(shè)計未必能滿足各種業(yè)務(wù)要求，應(yīng)當(dāng)要允許那些互相矛盾、重復(fù)或交叉的非功能特性存在。

17. Business Drives by Dave Muirhead

【業(yè)務(wù)決定技術(shù)】

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

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

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

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

19. Architects must be handson by John Davies

【架構(gòu)師必須是注重實踐】

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

20. Continuously Integrate by Dave Bartlett

【持續(xù)集成】

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

#p#

21. Avoid Scheduling Failures byNorman Carnovale

【避免延期】

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

22. Architectural Tradeoffs by Mark Richards

【架構(gòu)中的取舍】

沒有哪個系統(tǒng)能同時做到高性能、高可用、高安全、高通用。架構(gòu)師要帶領(lǐng)同事和客戶開誠布公地溝通，先滿足重要的目標(biāo)，再滿足次要的目標(biāo)。

23. Database as a Fortress by DanChak

【數(shù)據(jù)庫即堡壘】

開發(fā)團(tuán)隊的人員是流動的，用戶的人員也是來來往往的，但是架構(gòu)師要保證有一個東西不變，那就是數(shù)據(jù)庫結(jié)構(gòu)。從項目的第一天，就要抱著建造堡壘一樣的態(tài)度設(shè)計數(shù)據(jù)庫，使它能經(jīng)歷時間流逝和需求微調(diào)的考驗。

24. Use uncertainty as adriver by Kevlin Henney

【以不確定為動力】

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

25. Scope is the enemy ofsuccess by Dave Quick

【項目規(guī)模是成功的敵人】

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

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

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

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

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

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

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

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

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

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

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

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

【架構(gòu)中沒有“我”字】

不成熟的架構(gòu)師愛犯的毛病是：以為自己比客戶懂需求;把開發(fā)人員看作實現(xiàn)自己主張的資源;聽不進(jìn)和自己不同的意見。

以下認(rèn)識有助于架構(gòu)師的成長：

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

(2). 架構(gòu)不是架構(gòu)師一個人的，是整個團(tuán)隊的，架構(gòu)師需要隊員遠(yuǎn)勝于隊員需要架構(gòu)師，因此要從心底尊重他們、團(tuán)結(jié)他們。

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

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

28. Get the 1000ft view by Erik Doernenburg

【生成低空視圖】

要了解地面的情況，需要適當(dāng)?shù)母叨?。?0000英尺的高空只能看到大塊的輪廓，不能看到它的結(jié)構(gòu);在地面則迷失在身邊的細(xì)節(jié)里而失去整體感覺;在大約1000英尺的低空，剛好能看清楚地面的結(jié)構(gòu)。類似地，要了解軟件系統(tǒng)的質(zhì)量也要適當(dāng)?shù)木嚯x。系統(tǒng)架構(gòu)圖太宏觀，很多關(guān)系不清楚;源代碼又太微觀，關(guān)系太瑣碎;只有在類和方法這一級生成圖表，才能評估軟件的質(zhì)量。

29. Try before choosing by Erik Doernenburg

【試了再選】

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

30. Understand The BusinessDomain by Mark Richards

【了解業(yè)務(wù)領(lǐng)域】

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

31. Programming is an act ofdesign by Einar Landre

【編程是創(chuàng)意設(shè)計，不是照圖施工】

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

32. Time changes everything by Philip Nelson

【時間改變一切】

隨著時間的流逝，當(dāng)初各路高手所設(shè)計的高瞻遠(yuǎn)矚、機(jī)關(guān)算盡的框架、模式、范例、算法，有的如過眼云煙般消散得無影無蹤了，有的則最終流傳下來。歷史帶給我們?nèi)齻€啟示：

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

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

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

33. Give developers autonomy by Philip Nelson

【讓開發(fā)人員自治】

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

34. Value stewardship overshowmanship by Barry Hawkins

【做管家，不做演員】

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

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

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

【問題可能大于表象】

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

對問題習(xí)以為常的溫水煮青蛙效應(yīng);

人們對新經(jīng)歷、新知識的畏懼心理;

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

組員只關(guān)心個人目標(biāo)不重視全局目標(biāo);

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

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

建立組織級別的風(fēng)險管理機(jī)制;

不搞少數(shù)服從多數(shù)，要鼓勵悲觀論調(diào)并進(jìn)行討論，進(jìn)而提出中立的對策;

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

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

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

【軟件架構(gòu)師是新興職業(yè)】

軟件架構(gòu)師是一門新興的職業(yè)，可是它具有律師、醫(yī)生、建筑師一樣的精英特質(zhì)。大家努力吧!

37. Software architecture hasethical consequences by Michael Nygard

【軟件架構(gòu)也有倫理后果】

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

38. Everything will ultimatelyfail by Michael Nygard

【萬物皆會出錯】

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

軟件會出錯，所以用監(jiān)控軟件來對付?？墒潜O(jiān)控軟件也是軟件啊，所以錯誤還是不可避免。

網(wǎng)絡(luò)是由硬件和軟件組成的，所以網(wǎng)絡(luò)的錯誤就是難免的了。

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

39. Context is King by Edward Garson

【情景為王】

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

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

【處處都要考慮性能】

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

#p#

41. Engineer in the whitespaces by Michael Nygard

【設(shè)計空白處】

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

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

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

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

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

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

42. Talk the Talk by Mark Richards

【入行說行話】

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

43. Heterogeneity Wins by Edward Garson

【異構(gòu)取勝】

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

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

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

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

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

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

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

國王(Kings)： 他們是領(lǐng)袖，知道如何調(diào)遣其他角色。

架構(gòu)師好比是國王，該熟悉各個角色，還要保證所設(shè)計的架構(gòu)中具有這些角色的位置。只為個別角色設(shè)計架構(gòu)，就只能吸引個別的角色，不能發(fā)揮大家的特長。一個好國王，會給大家樹立追求的愿景，會讓大家各司其責(zé)，共同學(xué)習(xí)，共同成長，實現(xiàn)目標(biāo)。

45. Learn from Architects ofBuildings by Keith Braithwaite

【向建筑師學(xué)習(xí)】

“建筑是一種社會行為，是人類活動的物質(zhì)場所?！薄猄piro Kostof

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

“良好的教育和豐富的心靈也許能造就偉大的頭腦，卻不能造就偉大的建筑?！薄狥rank Lloyd Wright

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

“醫(yī)生出了錯可以將死人埋掉，建筑師出了錯只能讓客戶種爬藤遮丑?！薄猧bid

(避免設(shè)計錯誤很重要)

“建筑師堅信，不僅要做上帝身邊的助手，還應(yīng)該伺機(jī)取得上帝的寶座?！薄狵aren Moyer

(要立志精通客戶的業(yè)務(wù))

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

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

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

(美很重要)

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

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

46. Fight repetition by NiclasNilsson

【消除重復(fù)】

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

47. .Welcome to the Real World byGregor Hohpe

【走進(jìn)現(xiàn)實世界】

工程師喜歡精確，01世界的軟件工程師尤其喜歡按部就班的順序處理，喜歡是非分明?？墒乾F(xiàn)實世界卻是凌亂的。客戶下單之后很快又要取消，支票被拒付，信件丟失，付款延期，承諾落空。用戶不按要求輸入數(shù)據(jù)，不按規(guī)定步驟操作。分布式系統(tǒng)帶來了更多的不一致性：服務(wù)連不通，不發(fā)通知就改接口，沒有事務(wù)保證?，F(xiàn)實就是這個樣子，早晚總會出問題，你得承認(rèn)它。但也別太害怕。事件驅(qū)動編程、狀態(tài)機(jī)模式、錯誤重試等這些都是可以采用的技術(shù)。只是，在現(xiàn)實世界里，你要記?。盒前涂丝Х鹊瓴贿m用兩階段提交。

48. Don't Control, but Observe byGregor Hohpe

【寧觀察、不控制】

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

49. Janus the Architect by DaveBartlett

【向雅努斯學(xué)習(xí)】

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

50. Architects focus is on theboundaries and interfaces by EinarLandre

【架構(gòu)師關(guān)注邊界和接口】

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

51. Challenge assumptions -especially your own by Timothy High

【不要想當(dāng)然】

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

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

52. Record your rationale by Timothy High

【記錄你的理由】

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

53. Empower developers by Timothy High

【培養(yǎng)開發(fā)人員】

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

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

【軟件都跟數(shù)據(jù)有關(guān)】

一般討論編碼的時候，都是站在面向指令的視角，講命令、函數(shù)、算法?？墒且斫庖粋€復(fù)雜的系統(tǒng)(比如UNIX操作系統(tǒng))，就很難在成千上萬行代碼中理出頭緒。這時，如果我們關(guān)注代碼下面的數(shù)據(jù)(比如UNIX系統(tǒng)的文件、進(jìn)程等)，就相對容易理解些了。形成這種對比的原因是代碼很龐雜，而數(shù)據(jù)則很簡潔。后者就是面向數(shù)據(jù)的視角。大多數(shù)問題的核心是數(shù)據(jù)問題。關(guān)注數(shù)據(jù)，能更容易地處理復(fù)雜系統(tǒng)問題。要在系統(tǒng)建設(shè)早期完整地設(shè)計數(shù)據(jù)結(jié)構(gòu)，避免在系統(tǒng)建設(shè)過程中或投入運行后再來修改數(shù)據(jù)結(jié)構(gòu)。數(shù)據(jù)結(jié)構(gòu)修改將導(dǎo)致大量的代碼修改。

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

【控制數(shù)據(jù)，而不只是代碼】

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

56. Don't Stretch The ArchitectureMetaphors by David Ing

【不要讓比喻誤導(dǎo)他人】

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

57. Focus on Application Supportand Maintenance by Mncedisi Kasper

【關(guān)注應(yīng)用支持與維護(hù)】

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

58. Prepare to pick two by Bill dehOra

【學(xué)會三選二】

著名的Brewer猜想說：對于現(xiàn)代分布式應(yīng)用系統(tǒng)來說，數(shù)據(jù)一致性(Consistency)、系統(tǒng)可用性(Availability)、服務(wù)規(guī)模可分區(qū)性(Partitioning)三個目標(biāo)(合稱CAP)不可同時滿足，最多只能選擇兩個。

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

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

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

#p#

60. Start with a Walking Skeletonby Clint Shank

【從可行走的骨架開始】

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

61. Share your knowledge andexperiencesby Paul W. Homer

【分享你的知識和經(jīng)驗】

軟件業(yè)是一個年輕的行業(yè)，每個人都需要學(xué)習(xí)和進(jìn)步。和他人分享你的知識、經(jīng)驗，讓我們大家都發(fā)揮出全部的潛力，讓這個行業(yè)的明天更加燦爛。

62. Make sure the simple stuff issimple by Chad LaVigne

【簡單事情簡單辦】

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

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

【只設(shè)計自己會編碼的架構(gòu)】

架構(gòu)師總是想創(chuàng)造精巧而新潮的設(shè)計?？墒沁@樣的設(shè)計對項目其實是有影響的。如果使用了一些自己沒有動手做過的框架或者模式，不僅不能準(zhǔn)確地估計工作量，而且還帶來開發(fā)人員學(xué)習(xí)周期不明、新元素隱藏的問題不明、削弱開發(fā)人員對架構(gòu)師的信任、給項目帶來不必要的風(fēng)險等副作用。記?。杭軜?gòu)師首先是開發(fā)人員。

64. The ROI variable by GeorgeMalamidis

【計算投資回報】

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

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

【系統(tǒng)即遺產(chǎn)，需要精心設(shè)計】

一個系統(tǒng)即便最業(yè)務(wù)前衛(wèi)、技術(shù)先進(jìn)，對于下一任負(fù)責(zé)人來說，也是一份遺產(chǎn)。當(dāng)今軟件的特點就是迅速淘汰。如果想自己的系統(tǒng)投入生產(chǎn)，存活哪怕只是幾個月，也得接受一個現(xiàn)實，那就是維護(hù)人員需要修修補補。這意味著：

清楚——各個組件和類的執(zhí)行條理清楚;

可測——系統(tǒng)各部分的特性容易驗證;

正確——系統(tǒng)按設(shè)計或常規(guī)運行;

追溯——為不了解系統(tǒng)內(nèi)部情況的人提供問題追溯信息，以便快速定位和修復(fù)缺陷。

要抱著為繼任者留下遺產(chǎn)的態(tài)度來設(shè)計系統(tǒng)。

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

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

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

67. Understand the impact of changeby Doug Crawford

【理解變化的影響】

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

68. You have to understand Hardwaretoo by Kamal Wickramanayake

【必須了解硬件】

架構(gòu)師不僅要關(guān)注軟件架構(gòu)，也要關(guān)注硬件容量。硬件容量規(guī)劃是系統(tǒng)設(shè)計中的一個重要部分。如何準(zhǔn)確地預(yù)測用戶數(shù)量及其變化趨勢，如何評估硬件的發(fā)展，都是做容量規(guī)劃的必備知識。

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

【現(xiàn)在節(jié)省的，將來加倍還】

在項目開發(fā)階段，可能會省略哪些不產(chǎn)生直接價值的工作，比如單元測試，又比如設(shè)計優(yōu)化?，F(xiàn)在節(jié)省了一點工作，將來系統(tǒng)進(jìn)入維護(hù)階段以后，要改正隱藏的錯誤，要花幾倍的代價。

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

【優(yōu)秀是良好的敵人】

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

71. Avoid "Good Ideas"by Greg Nyberg

【別提“好點子”】

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

“如果在這里改動一下，就太酷了?！?/p>

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

“一邊開發(fā)新模塊，一邊重構(gòu)老模塊?！?/p>

“這項技術(shù)太強(qiáng)大了，可以用在我們的項目上?！?/p>

“我?guī)湍阆肓艘幌拢l(fā)現(xiàn)一個好主意!”

這些好點子往往是項目殺手。一旦付諸實踐，對項目造成的改動不是當(dāng)初想象的那么簡單。除了極個別之外，大部分會把項目慢慢地拖入深淵，有的甚至?xí)岉椖垦杆偈　?/p>

72. Great content creates greatsystems by Zubin Wadia

【好內(nèi)容成就好系統(tǒng)】

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

73. The Business Vs. The AngryArchitect by Chad LaVigne

【業(yè)務(wù)人員與憤怒的架構(gòu)師】

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

74. Stretch key dimensions to seewhat breaks by Stephen Jones

【撐大關(guān)鍵維度，發(fā)現(xiàn)破綻】

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

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

【架構(gòu)師首先是開發(fā)者】

架構(gòu)設(shè)計要落實到開發(fā)工作。如果你設(shè)計它，你就要能夠編碼它。如果連你都不知道如何編碼，別指望別人能編碼。

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

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

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

77. Stable problems get highquality solutions by Sam Gardiner

【穩(wěn)定的問題才有優(yōu)質(zhì)的解決方案】

現(xiàn)實世界的解決方案不是挑戰(zhàn)有難度的學(xué)術(shù)研究。設(shè)計現(xiàn)實的方案時，要把問題劃分為穩(wěn)定、有限的小塊，再針對明確的小塊來進(jìn)行解決。穩(wěn)定的問題得到穩(wěn)定的設(shè)計，穩(wěn)定的設(shè)計得到優(yōu)質(zhì)的解決方案。

78. It Takes Diligence by BrianHart

【勤勉】

一招不慎，滿盤皆輸。架構(gòu)師應(yīng)當(dāng)勤勉，認(rèn)認(rèn)真真做好每一項平凡的工作。

79. Take responsibility for yourdecisions by Yi Zhou

【對決策負(fù)責(zé)】

大約三分之二的項目是失敗的，表現(xiàn)有工期延誤、預(yù)算超支、用戶不滿等。失敗的重要原因是架構(gòu)不當(dāng)。通過以下幾條，可以做到對架構(gòu)決策負(fù)責(zé)：

準(zhǔn)備決策時，務(wù)必反復(fù)推敲;

進(jìn)行決策時，務(wù)必決策有據(jù)(書面憑據(jù));

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

有疑難問題，請教領(lǐng)域?qū)＜摇?/p>

#p#

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

【不做解題機(jī)】

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

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

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

【在恰當(dāng)?shù)臅r候，鳥槍換炮】

架構(gòu)師的武器庫中，有自己歷經(jīng)大小戰(zhàn)役的各式武器。新武器紛紛出世，該換的時候就得換。但換武器也得考慮時機(jī)。

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

二要評估成本：掌握新技術(shù)所花費的人力物力是否負(fù)擔(dān)得起?

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

82. Your Customer is Not YourCustomer by Eben Hewitt

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

當(dāng)討論需求的時候，不要只顧著聽客戶的陳述?？蛻粢苍S不了解他的客戶想要什么。而找出他的客戶(系統(tǒng)的終端用戶)的真實需求，是系統(tǒng)成功的必要條件。所以說，客戶的客戶，才是我們的客戶。要關(guān)心客戶的客戶。

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

【系統(tǒng)不會是設(shè)計的模樣】

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

84. Choose Frameworks that playwell with others by Eric Hawthorne

【選擇好搭配的框架】

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

85. Make a strong businesscase by Yi Zhou

【搞定一個強(qiáng)大的業(yè)務(wù)專案】

以下五步，助你做成一個強(qiáng)大的業(yè)務(wù)專案。

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

制定量化指標(biāo)：帶來的豐厚回報包括哪些合理的數(shù)據(jù)指標(biāo)?

換成傳統(tǒng)標(biāo)準(zhǔn)：把這些數(shù)據(jù)指標(biāo)換算成傳統(tǒng)的業(yè)務(wù)標(biāo)準(zhǔn)——金錢，它們是多少?

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

尋找恰當(dāng)時機(jī)：什么時候用戶比較能接受我們的提議?比如另一個架構(gòu)慘遭失敗的時候。

86. Pattern Pathology by Chad LaVigne

【模式病】

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

87. Learn a new language by Burk Hufnagel

【學(xué)習(xí)新語言】

要學(xué)習(xí)業(yè)務(wù)部門的業(yè)務(wù)語言，才能和他們有效溝通。

要學(xué)習(xí)編程人員的技術(shù)語言，才能和他們有效溝通。

88. Don't Be Clever by Eben Hewitt

【不要聰明要愚笨】

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

89. Build Systems to be Zuhanden byKeith Braithwaite

【建造應(yīng)手的系統(tǒng)】

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

90. Find and retain passionate problemsolvers by Chad LaVigne

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

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

91. Software doesn’t really existby Chad LaVigne

【軟件無形】

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

92. Pay down your technical debtby Burk Hufnagel

【償還技術(shù)債務(wù)】

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

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

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

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

94. The User Acceptance Problem byNorman Carnovale

【用戶接受問題】

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

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

(2) 有的人害怕未經(jīng)檢驗的新技術(shù)。

(3) 有的人擔(dān)心成本/預(yù)算。

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

針對不同的擔(dān)憂，用培訓(xùn)、演示等方式與用戶分享新系統(tǒng)帶來的好處、新系統(tǒng)的局限，促進(jìn)用戶接受新系統(tǒng)。

95. The Importance of Consommé by Eben Hewitt

【清湯的重要性】

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

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

【對于終端用戶，界面就是系統(tǒng)】

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

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

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

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

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

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