架構師的行為準則（三）

讓開發人員自己做主

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

控制專案規模

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

抓住真正需求

分而治之

設定優先順序

盡快交付原則

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

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

關注效能

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

對複雜性要有前瞻意識

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

關注邊界和介面

任何系統或模組的邊界和介面都是與外互動的門面，有互動就暗藏著誤解和不恰當的劃分，保持介面的順暢互動是架構師的重要職責。往往bug發生在模組與模組之間、系統與系統之間，專案的失敗也往往因為系統間互動問題，因此架構師需要給予足夠的關注

助力開發人員

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

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

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

參與開發團隊的招聘工作

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

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

直接參與開發，分擔壓力

記錄決策的理由

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

質疑假設

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

關注系統的支援和維護

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

清晰性

可測性

正確性

可跟蹤性

不要急於求解

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

優秀軟體是培育出來的

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