架構師必須瞭解的30條設計原則

做者：Srinath Perera

衆所周知，架構師的角色，更偏向於策劃、而非指揮，塑造、而非支配，其存在的意義，在於引導你們討論、而非本身主宰一切。

可是，具體應該如何執行呢？本文做者整理了 30 個公認的架構原則，來幫助你們解決此問題。也許有的原則，你從未據說，但你看完就能快速學會。

相信你學會了，工做起來也會事半功倍，或許還可幫你避免不少無用的加班！

在 WSO2，我參與架構評審的時間已長達八年之久。WSO2 的產品很是豐富，好比 WSO2 ESB 、WSO2 API Manager 以及 WSO2 SP 都人盡皆知。在過去八年中，咱們對許多產品和功能進行了討論、設計、改進和從新設計。

咱們在設計軟件的過程當中，把握的一個關鍵點是：軟件架構並不是由架構師負責設計。咱們的架構不是由架構師制定，而後交給其餘人來實施。

---

相反，架構的設計任務由真正編寫代碼的團隊負責。架構師負責對工程師設計的架構進行修復、完策劃和改進。咱們的架構團隊是指導員和把關人，而非獨裁者。

在短時間內，由一位架構師來制定架構的確既快捷又實惠。可是，從長遠來看，咱們會組建一個團隊，讓他們本身不斷思考、改善架構，並從他們的錯誤中來提高本身。

當咱們專一於團隊時，他們天然會隨着時間的推移而變得更好。架構團隊的首要任務是：儘量保證架構容易執行。此外，架構評審也存在缺陷。

就像 Paul 描述的架構評審那樣：架構師參與進來，聽一會，發表一點評論而後就走了。做爲一名架構師，你對架構發表本身的見解和意見無可厚非。可是，若是你不夠投入和細心，你的意見可能會讓團隊感到困惑，團隊就沒法肯定正確的作法究竟是什麼。

接下來我會將30個架構原則一一列出，其中一些原則是衆所周知的，而有些則源於個人我的經驗和心血。

基本原則

原則1： KISS (Keep it simple,sutpid) 和保持每件事情都儘量的簡單，用最簡單的解決方案來解決問題。

原則2：YAGNI（你不須要它）原則 ，只在須要時構建。

原則3：先學會爬，而後再學會走，最後學會跑。換句話說，先保證可以正常運行，而後優化它使其更好，最後逐漸讓它變得完美。使用迭dai開發，採用敏捷開發模式。爲每一個功能制定一個開發週期（最多2周），而後不斷迭代。

原則4：自動化測試是構建穩定、高質量產品的惟一方法。經過自動化測試提高創造力，全部一切均可以自動化！在設計時應當好好考慮自動化。

原則5：注重投資回報率（ROI）並將最多的注意力放在最重要的地方。

原則6：瞭解用戶並相應地平衡資源。大多數產品都有數千個最終用戶，大體須要20個開發人員和100個 DevOps 人員。不要花費數月的時間來構建一個不太可能使用 DevOps 的用戶界面（他們更喜歡腳本）。這是原則5的特例。

原則7：功能的設計和測試儘量獨立。若是在設計時考慮到這一點，長遠來看，它將省去不少麻煩，不然只有一切構建完成時你才能夠開始測試整個系統。此外，遵循這個原則，版本發佈也會更加順利。

原則8：警戒搜索引擎中花裏胡哨的架構方案。咱們天生都喜歡使人奪目的設計。若是你按奈不住， 就可能把太多根本不須要的功能和解決方案引入到你的架構中。

功能選擇

原則9：想要準確知道用戶如何使用咱們的產品是很難的。因此咱們要推行MVP（最小可行產品）。該理念的核心在於：先制定一些用例，完成用例所涉及的相關功能，當即發佈產品，而後根據反饋和經驗對產品進行優化。

原則10：儘量減小功能，若有疑問則將其刪除。許多功能可能從未使用，你只需爲其留一個擴展接口便可。

原則11：聽取客戶的意見，看他們想要什麼功能。

原則12：當客戶要求的功能影響到其餘模塊時，要敢於和客戶辯論。從大局出發，嘗試找到另外一種方法來處理問題。就像 Fords 所說的那樣「每當我問顧客須要什麼的時候,他們老是會說須要跑得更快的馬」。請記住，你纔是專家。你應該主導一切，作出正確和專業的決定。雖然用戶可能當時有些疑惑，但最終他們會感謝你的。

服務端設計和併發

原則13：要知道一個server是如何運行的，從硬件到操做系統，直到編程語言。優化IO調用的數量是你通往最好架構的首選之路。

原則14：遵循 Amdhal 的同步定律。線程之間共享的可變數據會下降程序速度。若是能夠，請使用併發數據結構，而且僅在必要時使用同步。儘量少地使用鎖。若是你打算在線程鎖期間阻塞，請確保本身足夠了解具體細節，由於這裏存在極大的隱患。

原則15：若是你的設計是基於事件驅動的非阻塞架構，那就不要阻塞線程或者在線程中執行 IO 操做。一旦這樣作，系統將慢如蝸牛。

分佈式系統

原則16：無狀態系統具備良好的擴展性。咱們要儘量瞭解和使用無分享架構。

原則17：除非你可以掌控客戶端和服務器的全部代碼，不然消息傳遞失敗的狀況在所不免。儘可能減小你的系統依賴的因素（例如使用原則18）。

原則18：儘量實施冪等操做。這樣它就很容易恢復，你至少能夠保證交付沒問題。

原則19：瞭解 CAP 定理。可擴展的事務（分佈式事務）是很難的 。儘量使用補償，基於 RDBMS 的事務很難擴展。

原則20：分佈式系統共識不支持擴展，也沒法進行組通訊，不支持羣集範圍內的可靠消息傳遞。其最大節點限制大約是八個節點。

原則21：在分佈式系統中，你很難隱藏分佈式系統中的延遲和故障。（參見分佈式計算的謬誤解釋 ）。

用戶體驗

原則22：瞭解你的用戶以及他們的目標：他是新手、專家仍是臨時用戶？他對計算機科學瞭解多少？極客看重擴展功能，開發人員關注示例和腳本，普通人則更在意界面。

原則23：最好的產品應當不須要用戶手冊，用戶應該一看就會用。

原則24：當你沒法在兩個選項之間作出決定時，請不要經過配置選項的方式來呈現問題。這會給用戶和架構師帶來麻煩。對於系統如何運做的細節，他們沒有你瞭解，他們怎麼能作出決定呢？最好的方案是找到一個每次都有效的選擇；其次是自動作出選擇；第三個方案是添加配置參數並設置合理的默認值。

原則25：始終具備合理的配置默認值。

原則26：設計不良的配置會製造麻煩，始終配置幾個示例值。

原則27：詢問用戶配置值的時候，注意選擇用戶無需便可設置的值（例如，不要問用戶須要的最大緩存條目數量，而是要問他想要用於緩存的內存數量）

原則28：若是發現未知配置，則拋出錯誤。永遠不要忽視它。在調試過程當中，無提示的配置錯誤會浪費咱們不少調式時間。

難點

原則29：嘗試新語言很容易，但要正確使用卻很難。除非公司願意組建一個十人團隊並花一年的時間來學習，不然儘可能不要這樣作。若是你仍不死心，請閱讀有關語言設計的五個問題後再作定奪。

原則30：可組合的拖放 UI 很難實現，除非團隊準備投入10人年的資源，不然不要去作。

最後，談一下個人感覺。在理想狀況下，一個平臺應當由多個正交組件組成，每一個組件負責一個方面（例如，安全性、消息傳遞、註冊、調解、分析，等等）。使用這些功能構建的系統將是最佳的。

不幸的是，現實中咱們很難達到這樣的狀態。由於在項目初始狀態時，不少事情是不肯定的，你沒法作到這樣的獨立性，如今我認爲在開始的時候適當的重複是必要的，當你嘗試剷除他們的時候，你會發現引入了新的複雜性，分佈自己就意味着複雜。有時候治癒的過程要比疾病自己更加的糟糕。

---

總結

做爲一個架構師，咱們應該像園丁同樣思考、塑造、策劃和去除雜草而不是定義和構建。雖然在短時間內，由一位架構師來制定架構的確既快捷又實惠。可是，從長遠來看，團隊的力量纔是最強的。

若是你不夠投入和細心，你只指出錯誤，可是不道明錯誤緣由，那麼你的意見可能會讓團隊感到困惑。避免這種狀況的一種方法是擁有一套廣泛接受的原則，這些原則是討論架構時遵循的基本點，也是初學者學習架構的好資源。因此想成爲 一名優秀的架構師，仍是須要長期的磨練以及時間的驗證，固然隨時保持學習的狀態也是很是重要的。當你學會更多知識，你便會更清晰的解決各類複雜的架構問題。

---

感謝你們能耐着性子，看完我囉哩囉嗦的文章

咱們做爲程序員，想要成爲架構師，這個過程是漫長且艱難的……

在這裏我也分享一份本身收錄整理的Android學習PDF+架構視頻+面試文檔+源碼筆記，還有高級架構技術進階腦圖、Android開發面試專題資料，高級進階架構資料幫助你們學習提高進階，也節省你們在網上搜索資料的時間來學習，也能夠分享給身邊好友一塊兒學習

若是你有須要的話，能夠點贊+評論