【轉載】架構師的行為準則（三）

讓開發人員自己做主 

      架構師雖然需要為系統的設計負責，但無須包攬所有的設計工作，應該給予團隊成員足夠的自主權，讓他們發揮自己的創意和能力，你的工作是確定大家的工作能很好的組合在一起，幫助他人解決棘手困難。當你發現同僚遇到麻煩時，可以主動給出建議，但更可取的做法是創造良好的氛圍，讓大家主動向你征求意見。 

控制項目規模 

      架構師要試圖避免做那種“超大型”系統，因為這種系統往往難以控制，控制項目規模的辦法通常有： 

抓住真正需求

分而治之

設定優先級

盡快傳遞原則

架構師不是演員，而是管家

      有些架構師誤解了證明自己價值的含義，以為是炫耀技術才華，甚至是刁難開發團隊，把自己放在高高在上的位子，試圖讓别人來崇拜你。其實架構師的職責和管家類似，承擔着管理技術資産的責任，要深入了解系統裡各個細節，要精打細算，而不是浮在表面做無實文章。 

關注性能 

      高性能往往和代碼優美性常常沒法相容，有些架構師往往不在乎性能上的點滴損耗，為了代碼更重用或更優美，不惜多查一次資料庫，多與外系統互動一次，這種做法會讓後期的性能提升很被動，性能壓力會逼迫你打破原有的設計，為提升性能把代碼搞得支離破碎。架構師需要珍惜任何一點的性能損耗。 

對複雜性要有前瞻意識 

      在實際的運作環境中，往往簡單的系統都有可能變得非常複雜，簡單的遠端接口可能調不通、穩固的資料庫可能down掉、消息順序可能會錯亂、伺服器可能會無緣無故地down機，不要假設這些情況不會發生，架構師應該對複雜的情況有前瞻意識，要在假設類似于前面的狀态存在的情況下設計軟體。 

關注邊界和接口 

      任何系統或子產品的邊界和接口都是與外互動的門面，有互動就暗藏着誤解和不恰當的劃分，保持接口的順暢互動是架構師的重要職責。往往bug發生在子產品與子產品之間、系統與系統之間，項目的失敗也往往因為系統間互動問題，是以架構師需要給予足夠的關注。 

助力開發人員 

      架構師的完美設計需要開發人員是實作，是以有義務想辦法提升開發團隊的戰鬥力，常有以下方式： 

尋找或開發工作需要的工具，并附上使用技巧

做定期的分享或提高團隊學習氣氛，保持團隊技術上的先進性

參與開發團隊的招聘工作

給予開發人員更多的決策空間，幫助其成長

保護好開發人員，讓他們盡可能地免于雜事之中

直接參與開發，分擔壓力

記錄決策的理由

架構師常常需要權衡和決策，但決策過後卻沒有把決策的過程和理由記錄下來，其實這是在浪費很大的一筆财富。 

質疑假設 

      架構師往往需要假設一種情境，然後在這種情境下給出方案和做出決策，很多人包括自己從來都是糾結于這個方案的優劣，并不斷改進，但卻忽視了這種假設的情境是否成立，而這個可能是萬惡之源。 

關注系統的支援和維護 

      架構師通常是由開發人員成長而來，是以天然地把注意力放在功能開發上，常常忽視系統的支援和維護方面，給支援人員和維護人員造成不便。架構師需要清晰知道一個系統生命周期80%在于維護上面，而系統的價值需要支援人員去不斷傳遞給客戶，他們的需求需要得到重視。有以下幾點需要注意： 

清晰性

可測性

正确性

可跟蹤性

不要急于求解

      很多架構師都有解決難題的欲望，一遇到問題，就立馬陷入解決問題的泥潭中。而更可取的做法是審視問題本身，看是否可以改變問題，或是幹脆繞開問題，很多時候技術上的難題在通過業務上的優化是可以避免的。我們不要立足點設為解決特定問題，而是應該立足于客戶需求。 

優秀軟體是培育出來的 

      很多架構師需要在軟體的第一版本就一鳴驚人，拿出完美的作品，其實真正受歡迎的系統是在不斷釋出中演化而來，對于網際網路軟體更是如此。架構師需要做的是打好系統的基礎，使其容易修改和擴充，傾聽使用者的回報，不斷地在無數次改進中培育我們的軟體。