成就職業(yè)理想：九十七條架構師必知的事情
51CTO 發(fā)表于：11年06月29日 10:16 [轉(zhuǎn)載] 51CTO
21. Avoid Scheduling Failures byNorman Carnovale
【避免延期】
人的工作能力是有限的。同樣的工期內(nèi)要增加工作量，就難免延期。不增加工作量但是強求縮短工期反而常常導致延期。因為，趕工通常造成設計不良、缺陷數(shù)量上升、測試不足等問題，日后處理這些問題反而需要更多的時間。因此，碰到有人要求縮短工期，應堅決主張原定工期。確實必須縮短工期的，就要將部分非必需功能從開發(fā)任務中剔除，留待下一期開發(fā)中去處理。這是一個協(xié)商談判的過程，架構師要有一定的技巧才能處理好。
22. Architectural Tradeoffs by Mark Richards
【架構中的取舍】
沒有哪個系統(tǒng)能同時做到高性能、高可用、高安全、高通用。架構師要帶領同事和客戶開誠布公地溝通，先滿足重要的目標，再滿足次要的目標。
23. Database as a Fortress by DanChak
【數(shù)據(jù)庫即堡壘】
開發(fā)團隊的人員是流動的，用戶的人員也是來來往往的，但是架構師要保證有一個東西不變，那就是數(shù)據(jù)庫結構。從項目的第一天，就要抱著建造堡壘一樣的態(tài)度設計數(shù)據(jù)庫，使它能經(jīng)歷時間流逝和需求微調(diào)的考驗。
24. Use uncertainty as adriver by Kevlin Henney
【以不確定為動力】
生活中人們期待有多種選擇，可如果自己設計軟件，卻往往喜歡省事，在幾個選項中只采用一個。如此一來，軟件對用戶就不那么平滑順手。一個設計是否良好，是用修改所需的成本來衡量的。當遇到技術上的選擇時，不要匆忙決定，要退一步想想有沒有不進行選擇的辦法?只在是非分明、條件明確的情況下才需要選擇。
25. Scope is the enemy ofsuccess by Dave Quick
【項目規(guī)模是成功的敵人】
架構師如果好大喜功，不切實際地擴充項目的范圍，在時間、人力、物力、功能、質(zhì)量等級、交付難度、風險系數(shù)、約束條件等方面不斷加碼，使項目變大、變復雜，那么就是在促使項目走向失敗。當項目規(guī)模擴充時，失敗的可能性也在以更快的速度增加。以下是避免規(guī)模增長的幾個策略：
(1). 求真務實：真實的需求是什么(客戶的底線在哪里)?
(2). 各個擊破：這個項目不能再分解成幾個各自獨立的小項目嗎?
(3). 主次有別：哪些是重要而穩(wěn)定的需求?哪些是次要而易變的需求?
(4). 及早發(fā)布：錯誤是不可完全避免的，早點讓用戶見到作品就是給自己留下改正錯誤的時間。
26. Reuse is about people andeducation, not just architecture byJeremy Meyer
【重用要靠受過教育的人員】
一個設計良好、漂亮、可重用的框架或者代碼庫，只能由了解它、會用它、相信它的人來使用。
(1). 了解：沒有人會去查找自己不知道的東西，只有在公司中將它的信息推送到開發(fā)人員和設計人員面前，他們才會了解它。
(2). 會用：一點便通的人很少，大多數(shù)人必須經(jīng)過培訓才會使用它。
(3). 相信：新來的人往往瞧不起舊的東西，他們傾向于通過重頭編寫來證明自己的才能，要設法讓他們相信重用成熟穩(wěn)定的組件框架勝過自己編寫。
27. There is no 'I' inarchitecture by Dave Quick
【架構中沒有“我”字】
不成熟的架構師愛犯的毛病是：以為自己比客戶懂需求;把開發(fā)人員看作實現(xiàn)自己主張的資源;聽不進和自己不同的意見。
以下認識有助于架構師的成長：
(1). 不是架構師決定架構，是完整準確的需求決定架構，因此要密切接觸客戶進行需求分析。
(2). 架構不是架構師一個人的，是整個團隊的，架構師需要隊員遠勝于隊員需要架構師，因此要從心底尊重他們、團結他們。
(3). 模型不算是架構，只有能用的模型才是架構，因此要和組員一起進行演練以便檢查確認模型能支撐需求。
(4). 自我肯定、自我保護是人的天性，遇到壓力便表現(xiàn)出來，因此要每天花幾分鐘審視自己：是否對他人表達了應有的敬意和謝意?是否冷淡了他人的善意?是否真的明白他人為何與自己意見不同?
28. Get the 1000ft view by Erik Doernenburg
【生成低空視圖】
要了解地面的情況，需要適當?shù)母叨取Ｔ?0000英尺的高空只能看到大塊的輪廓，不能看到它的結構;在地面則迷失在身邊的細節(jié)里而失去整體感覺;在大約1000英尺的低空，剛好能看清楚地面的結構。類似地，要了解軟件系統(tǒng)的質(zhì)量也要適當?shù)木嚯x。系統(tǒng)架構圖太宏觀，很多關系不清楚;源代碼又太微觀，關系太瑣碎;只有在類和方法這一級生成圖表，才能評估軟件的質(zhì)量。
29. Try before choosing by Erik Doernenburg
【試了再選】
選擇哪一個框架?使用哪個代碼庫?架構師不能坐在象牙塔的頂端做出設計并頒布給開發(fā)人員使用。在做出技術選擇之前，他應該放低身段，找開發(fā)人員商量，讓他們對可選的幾種方案分別實現(xiàn)，再提出各自的建議，最后由架構師綜合分析決定使用哪一種方案。
30. Understand The BusinessDomain by Mark Richards
【了解業(yè)務領域】
軟件架構既要采用高超的技術，又要深刻地反映業(yè)務領域的特點，才能實現(xiàn)業(yè)務目標。比如，保險業(yè)適用面向服務的架構，金融業(yè)適用基于工作流的架構。了解業(yè)務的最高標準，就是能用業(yè)務語言和公司的老總級人物交流。業(yè)務領域的知識是不斷更新的，比如汽車保險業(yè)新出現(xiàn)的一種臨時停車保險，就是一種新的業(yè)務動向。能夠把握領域發(fā)展動向，就能未雨綢繆，當公司有需要時可以迅速提出解決方案。
31. Programming is an act ofdesign by Einar Landre
【編程是創(chuàng)意設計，不是照圖施工】
汽車廠要出一輛新汽車，必須經(jīng)歷概念車創(chuàng)意設計、流水線生產(chǎn)這兩大階段。軟件編程中，主要的工作是都是創(chuàng)意設計，很少照本宣科的。既然大家都知道設計新車型、開發(fā)新藥物這樣的工作往往不能按時完成，也不能確保成功，那么我們也不要指望軟件編程可以精確預測。
32. Time changes everything by Philip Nelson
【時間改變一切】
隨著時間的流逝，當初各路高手所設計的高瞻遠矚、機關算盡的框架、模式、范例、算法，有的如過眼云煙般消散得無影無蹤了，有的則最終流傳下來。歷史帶給我們?nèi)齻�啟示：
(1). 堅持有價值的領域：如果我們熟悉的領域已經(jīng)沒有價值，要勇于探索新的領域，即便早期的嘗試不成功，也要克服困難堅持下去，正確的領域總會有正確的方案，盡管它也許來得很晚。
(2). 簡單規(guī)則：克服我們自身把問題復雜化的傾向，讓方案保持簡單。想一想，那些復雜的東西，如今哪個還在呢?
(3). 珍惜舊東西：雖然過去的東西不完全適合于現(xiàn)在的情景，可是把經(jīng)歷了時間考驗的東西修一修，不是也很有把握滿足新的需要嗎?
33. Give developers autonomy by Philip Nelson
【讓開發(fā)人員自治】
架構師的職責不是要對開發(fā)人員如何工作進行指點。架構師的責任是在開發(fā)人員致力于編制類和方法、進行單元測試、創(chuàng)建數(shù)據(jù)庫時，保證這些部分合在一起能正常運行。了解他們的痛處，做出對應的改進。測試困難嗎?那就改善接口并減少依賴。領域抽象性不夠或過度?那就澄清它。開發(fā)順序不清楚?做個計劃吧。開發(fā)人員使用API時總犯相同的錯誤?那要把API的設計調(diào)整得更簡單明白。人們真的理解設計嗎?和他們交流闡述吧。不確定哪些地方需要伸縮性嗎?去和客戶交流并了解他們的業(yè)務模型吧。總之，架構師要給開發(fā)人員創(chuàng)造一個工作環(huán)境，而不是干涉開發(fā)人員份內(nèi)的工作。
34. Value stewardship overshowmanship by Barry Hawkins
【做管家，不做演員】
管家是為雇主精打細算的人，演員是為觀眾嘩眾取寵的人。
架構師提出的解決方案，關系到公司的人力、財力、物力和時間。公司把架構師職責授予一個人，他就要替公司平衡投入和產(chǎn)出比例。正如理財師要對客戶承諾收益率一樣，架構師也要時刻考慮公司的收益，而不能把項目當成自己顯擺的舞臺。
35. Warning, problems in mirror maybe larger than they appear by Dave Quick
【問題可能大于表象】
項目中出現(xiàn)問題，往往得不到重視，最后難于收拾。原因主要有：
對問題習以為常的溫水煮青蛙效應;
人們對新經(jīng)歷、新知識的畏懼心理;
開發(fā)人員不以為然的樂觀主義傾向;
組員只關心個人目標不重視全局目標;
人都有盲點，尤其是對自己的缺點視而不見。
要克服以上不利因素，可以從這幾方面著手：
建立組織級別的風險管理機制;
不搞少數(shù)服從多數(shù)，要鼓勵悲觀論調(diào)并進行討論，進而提出中立的對策;
敞開心胸，不斷聽取客戶意見;
讓自己信任的人指出自己的盲點。
36. The title of software architecthas only lower-case 'a's; deal with it by Barry Hawkins
【軟件架構師是新興職業(yè)】
軟件架構師是一門新興的職業(yè)，可是它具有律師、醫(yī)生、建筑師一樣的精英特質(zhì)。大家努力吧!
37. Software architecture hasethical consequences by Michael Nygard
【軟件架構也有倫理后果】
說到人權、身份盜用、惡意程序等等，人們知道軟件架構可以助人行善，也可以助人作惡。其實除了大是大非問題，平時很多地方都值得進行倫理思考。比如說，一個軟件好用則千萬個用戶都省事，一個軟件難用則千萬個用戶都麻煩，他們的輕松愉快或者垂頭喪氣不就取決于我們架構師嗎?為了他們長久的簡便，我們要承擔一時的幸苦。軟件影響太多的人了，不要設計違背倫理的軟件，哪怕一點點都不要做。
38. Everything will ultimatelyfail by Michael Nygard
【萬物皆會出錯】
硬件會出錯，所以用冗余來對付。
軟件會出錯，所以用監(jiān)控軟件來對付�？墒潜O(jiān)控軟件也是軟件啊，所以錯誤還是不可避免。
網(wǎng)絡是由硬件和軟件組成的，所以網(wǎng)絡的錯誤就是難免的了。
怎么辦?我們不能拒絕錯誤，我們必須接受錯誤。承認萬物皆會出錯，接著設計出適當?shù)氖∧Ｊ�，才能讓我們的系統(tǒng)安全地出錯。例如，承認汽車是會撞車的，然后設計可壓縮的部件來吸收撞擊的能量，起到保護乘客的作用。在軟件系統(tǒng)中，如果不設計失敗模式，失敗偏偏就會讓你措手不及。
39. Context is King by Edward Garson
【情景為王】
情景為王，簡單性是它謙恭的仆人。所謂情景，指的是業(yè)務驅(qū)動力、新興技術和思想潮流。首先要敞開思路，關注情景中各種各樣的因素，給它們排出優(yōu)先級，然后才能制定出簡單的解決方案。
40. It's all about performance by Craig L Russell
【處處都要考慮性能】
如果有一種車寬敞、舒適、省錢又環(huán)保，就一定賣得好嗎?非也。一輛牛車即使達到這樣的標準也未必有幾個人去買。原因就在于它速度太慢了。軟件設計也是一樣，功能重要，性能也一樣重要。性能不單單指系統(tǒng)響應時間，還包括用戶操作步數(shù)、用戶思考時間、用戶輸入時間等。性能還包括那些自動執(zhí)行而不與人互動的部分，比如每日夜間處理任務。試想一下，如果一個每天夜間執(zhí)行的任務到了第二天的夜間還沒執(zhí)行完，將會帶來難以預料的后果。
