【CSDN編者按】眾所周知，架構師的角色，更偏向於策劃、而非指揮，塑造、而非支配，其存在的意義，在於引導大家討論、而非自己主宰一切。

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

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

想一下軟體架構的評審過程：一位架構師參與進來，俯視一切然後指指點點，高談闊論。他發表的評論要麼過於粗淺，要麼嚴重脫離實際。

大家對其意見要麼極度沉默，要麼強烈反對。這對團隊幾乎沒有任何幫助。程式設計師和架構師都對這樣的架構評審望而生畏。

軟體架構師的角色應當像園丁而非指揮官。前者的職責主要是塑造、策劃並清除雜草，而後者主要任務是發號施令。

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

我們在設計軟體的過程中，把握的一個關鍵點是：軟體架構並非由架構師負責設計。我們的架構不是由架構師制定，然後交給其他人來實施。

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

在短期內，由一位架構師來制定架構的確既快捷又實惠。但是，從長遠來看，我們會組建一個團隊，讓他們自己不斷思考、改善架構，並從他們的錯誤中來提升自己。

當我們專注於團隊時，他們自然會隨著時間的推移而變得更好。架構團隊的首要任務是：儘可能保證架構容易執行。

此外，架構評審也存在缺陷。就像 Paul （@pzfreo）描述的架構評審那樣：架構師參與進來，聽一會，發表一點評論然後就走了。

作為一名架構師，你對架構發表自己的看法和意見無可厚非。但是，如果你不夠投入和細心，你的意見可能會讓團隊感到困惑，團隊就無法確定正確的做法到底是什麼。

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

                                                                                  基本原則

原則1： KISS（保持簡單）原則 ，儘可能讓一切變得簡單。該原則鼓勵我們用最簡單的解決方案來完成工作。

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

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

原則4：自動化測試是構建穩定、高質量產品的唯一方法。通過自動化測試提升創造力，所有一切都可以自動化!在設計時應當好好考慮自動化。

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

原則6：瞭解使用者並相應地平衡資源。大多數產品都有數千個終端使用者，大致需要20個開發人員和100個 DevOp 人員。不要花費數月的時間來構建一個不太可能使用 DevOp 的使用者介面（他們更喜歡指令碼！）。這是原則5的特例。

原則7：功能的設計和測試儘可能獨立。如果在設計時考慮到這一點，長遠來看，它將省去很多麻煩，否則只有一切構建完成時你才可以開始測試整個系統。此外，遵循這個原則，版本釋出也會更加順利。

原則8：警惕搜尋引擎中花裡胡哨的架構方案。我們天生都喜歡令人奪目的設計。如果你按奈不住， 就可能把太多根本不需要的功能和解決方案引入到你的架構中。

                                                                                選擇功能

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

原則10：儘可能減少功能，如有疑問則將其刪除。許多功能可能從未使用，你只需為其留一個擴充套件介面即可。

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

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

                                                                         伺服器設計與併發

原則13：從硬體、作業系統到你使用的程式語言等多方面深入瞭解伺服器的工作原理。優化 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人年的資源，否則不要去做。

最後，讓我談一些隨著時間的推移我的主意發生變化的事情。在理想情況下，一個平臺應當由多個元件組成，每個元件負責一個方面（例如，安全性、訊息傳遞、註冊、調解、分析，等等）。使用這些功能構建的系統將是最佳的。

不幸的是，嚴格執行這一點可能是一個錯誤，特別是在新功能的初始狀態，其中簡單的功能可能導致大的變化，因為我們試圖使一切都是垂直的。有時我們發現我們新增的功能沒用，然後所有額外的工作都沒有用。最後，如果這需要多個團隊之間的協商，該功能可能永遠都無法完成。

現在來看，我願意接受重複。治療帶來的結果可能會比疾病導致後果更嚴重。

                                                                      結論

作為架構師，我們應該像園丁一樣思考、塑造、策劃和去除雜草而不是定義和構建。

在短期內，由一位架構師來制定架構的確既快捷又實惠。但是，從長遠來看，團隊的力量才是最強的。

如果你不夠投入和細心，你只指出錯誤，但是不道明錯誤原因，那麼你的意見可能會讓團隊感到困惑。避免這種情況的一種方法是擁有一套普遍接受的原則，這些原則是討論架構時遵循的基本點，也是初學者學習架構的好資源。

原文：https://hackernoon.com/first-do-no-harm-30-principles-that-helped-me-avoid-fly-by-architecture-reviews-e8952ac632a

作者：Srinath Perera ，是一位電腦科學家、軟體架構師、作家，他是 apache 的核心成員，擁有 15 年分散式系統程式設計經驗，設計了 Apache Axis2 以及 WSO2 流處理器。

譯者：安翔，責編：胡巍巍