30条架构原则：助你成为大牛架构师
正文共：3684字
預(yù)計閱讀時間：5分鐘
【CSDN編者按】眾所周知，架構(gòu)師的角色，更偏向于策劃、而非指揮，塑造、而非支配，其存在的意義，在于引導(dǎo)大家討論、而非自己主宰一切。
但是，具體應(yīng)該如何執(zhí)行呢？本文作者整理了 30 個公認(rèn)的架構(gòu)原則，來幫助大家解決此問題。也許有的原則，你從未聽說，但你看完就能快速學(xué)會。
相信你學(xué)會了，工作起來也會事半功倍，或許還可幫你避免很多無用的加班！
想一下軟件架構(gòu)的評審過程：一位架構(gòu)師參與進(jìn)來，俯視一切然后指指點(diǎn)點(diǎn)，高談闊論。他發(fā)表的評論要么過于粗淺，要么嚴(yán)重脫離實(shí)際。
大家對其意見要么極度沉默，要么強(qiáng)烈反對。這對團(tuán)隊(duì)幾乎沒有任何幫助。程序員和架構(gòu)師都對這樣的架構(gòu)評審?fù)贰?/span>
軟件架構(gòu)師的角色應(yīng)當(dāng)像園丁而非指揮官。前者的職責(zé)主要是塑造、策劃并清除雜草，而后者主要任務(wù)是發(fā)號施令。
在 WSO2，我參與架構(gòu)評審的時間已長達(dá)八年之久。WSO2 的產(chǎn)品非常豐富，比如 WSO2 ESB 、WSO2 API Manager ?以及 WSO2 SP ?都人盡皆知。在過去八年中，我們對許多產(chǎn)品和功能進(jìn)行了討論、設(shè)計、改進(jìn)和重新設(shè)計。
我們在設(shè)計軟件的過程中，把握的一個關(guān)鍵點(diǎn)是：軟件架構(gòu)并非由架構(gòu)師負(fù)責(zé)設(shè)計。我們的架構(gòu)不是由架構(gòu)師制定，然后交給其他人來實(shí)施。
相反，架構(gòu)的設(shè)計任務(wù)由真正編寫代碼的團(tuán)隊(duì)負(fù)責(zé)。架構(gòu)師負(fù)責(zé)對工程師設(shè)計的架構(gòu)進(jìn)行修復(fù)、策劃和改進(jìn)。我們的架構(gòu)團(tuán)隊(duì)是指導(dǎo)員和把關(guān)人，而非獨(dú)裁者。
在短期內(nèi)，由一位架構(gòu)師來制定架構(gòu)的確既快捷又實(shí)惠。但是，從長遠(yuǎn)來看，我們會組建一個團(tuán)隊(duì)，讓他們自己不斷思考、改善架構(gòu)，并從他們的錯誤中來提升自己。
當(dāng)我們專注于團(tuán)隊(duì)時，他們自然會隨著時間的推移而變得更好。架構(gòu)團(tuán)隊(duì)的首要任務(wù)是：盡可能保證架構(gòu)容易執(zhí)行。
此外，架構(gòu)評審也存在缺陷。就像 Paul （@pzfreo）描述的架構(gòu)評審那樣：架構(gòu)師參與進(jìn)來，聽一會，發(fā)表一點(diǎn)評論然后就走了。
作為一名架構(gòu)師，你對架構(gòu)發(fā)表自己的看法和意見無可厚非。但是，如果你不夠投入和細(xì)心，你的意見可能會讓團(tuán)隊(duì)感到困惑，團(tuán)隊(duì)就無法確定正確的做法到底是什么。
接下來我會將30個架構(gòu)原則一一列出，其中一些原則是眾所周知的，而有些則源于我的個人經(jīng)驗(yàn)和心血。
基本原則
原則1：?KISS（Keep it simple 保持簡單）原則 ，盡可能讓一切變得簡單。該原則鼓勵我們用最簡單的解決方案來完成工作。
原則2：YAGNI（You aren't gonna need it 你不需要它）原則 ，只在需要時構(gòu)建。
原則3：先學(xué)會爬，然后再學(xué)會走，最后學(xué)會跑。換句話說，先保證能夠正常運(yùn)行，然后優(yōu)化它使其更好，最后逐漸讓它變得完美。使用迭代開發(fā)，采用敏捷開發(fā)模式。為每個功能制定一個開發(fā)周期（最多2周），然后不斷迭代。
原則4：自動化測試是構(gòu)建穩(wěn)定、高質(zhì)量產(chǎn)品的唯一方法。通過自動化測試提升創(chuàng)造力，所有一切都可以自動化!在設(shè)計時應(yīng)當(dāng)好好考慮自動化。
原則5：注重投資回報率Return of Investment（ROI）并將最多的注意力放在最重要的地方。
原則6：了解用戶并相應(yīng)地平衡資源。大多數(shù)產(chǎn)品都有數(shù)千個最終用戶，大致需要20個開發(fā)人員和100個 DevOp 人員。不要花費(fèi)數(shù)月的時間來構(gòu)建一個不太可能使用 DevOp 的用戶界面（他們更喜歡腳本！）。這是原則5的特例。
原則7：功能的設(shè)計和測試盡可能獨(dú)立。如果在設(shè)計時考慮到這一點(diǎn)，長遠(yuǎn)來看，它將省去很多麻煩，否則只有一切構(gòu)建完成時你才可以開始測試整個系統(tǒng)。此外，遵循這個原則，版本發(fā)布也會更加順利。
原則8：警惕搜索引擎中花里胡哨的架構(gòu)方案。我們天生都喜歡令人奪目的設(shè)計。如果你按捺不住， 就可能把太多根本不需要的功能和解決方案引入到你的架構(gòu)中。
選擇功能
原則9：想要準(zhǔn)確知道用戶如何使用我們的產(chǎn)品是很難的。所以我們要推行MVP（最小可行產(chǎn)品）。該理念的核心在于：先制定一些用例，完成用例所涉及的相關(guān)功能，立即發(fā)布產(chǎn)品，然后根據(jù)反饋和經(jīng)驗(yàn)對產(chǎn)品進(jìn)行優(yōu)化。
原則10：盡可能減少功能，如有疑問則將其刪除。許多功能可能從未使用，你只需為其留一個擴(kuò)展接口即可。
原則11：聽取客戶的意見，看他們想要什么功能。
原則12：當(dāng)客戶要求的功能影響到其他模塊時，要勇于和客戶辯論。從大局出發(fā)，嘗試找到另一種方法來處理問題。就像 Fords 所說的那樣“每當(dāng)我問顧客需要什么的時候,他們總是會說需要跑得更快的馬”。請記住，你才是專家。你應(yīng)該主導(dǎo)一切，做出正確和專業(yè)的決定。雖然用戶可能當(dāng)時有些疑惑，但最終他們會感謝你的。
服務(wù)器設(shè)計與并發(fā)
原則13：從硬件、操作系統(tǒng)到你使用的編程語言等多方面深入了解服務(wù)器的工作原理。優(yōu)化 IO 操作的效率是一個良好架構(gòu)的首要任務(wù)。
原則14：遵循 Amdhal 的同步定律。線程之間共享的可變數(shù)據(jù)會降低程序速度。如果可以，請使用并發(fā)數(shù)據(jù)結(jié)構(gòu)，并且僅在必要時使用同步。盡可能少地使用鎖。如果你打算在線程鎖期間阻塞，請確保自己足夠了解具體細(xì)節(jié)，因?yàn)檫@里存在極大的隱患。
原則15：如果你的設(shè)計是基于事件驅(qū)動的非阻塞架構(gòu)，那就不要阻塞線程或者在線程中執(zhí)行 IO 操作。一旦這樣做，系統(tǒng)將慢如蝸牛。
分布式系統(tǒng)
原則16：無狀態(tài)系統(tǒng)具有良好的擴(kuò)展性。我們要盡可能了解和使用無分享架構(gòu)。
原則17：除非你能夠掌控客戶端和服務(wù)器的所有代碼，否則消息傳遞失敗的情況在所難免。盡量減少你的系統(tǒng)依賴的因素（例如使用原則18）。
原則18：盡可能實(shí)施冪等操作。這樣它就很容易恢復(fù)，你至少可以保證交付沒問題。
原則19：了解 CAP 定理。擴(kuò)展事務(wù)很難。盡可能使用補(bǔ)償，基于 RDBMS 的事務(wù)很難擴(kuò)展。
原則20：分布式系統(tǒng)共識不支持?jǐn)U展，也無法進(jìn)行組通信，不支持群集范圍內(nèi)的可靠消息傳遞。其最大節(jié)點(diǎn)限制大約是八個節(jié)點(diǎn)。
原則21：你很難隱藏分布式系統(tǒng)中的延遲和故障。（參見分布式計算的謬誤解釋 ）。
用戶體驗(yàn)
原則22：了解你的用戶以及他們的目標(biāo)：他是新手、專家還是臨時用戶？他對計算機(jī)科學(xué)了解多少？極客看重擴(kuò)展功能，開發(fā)人員關(guān)注示例和腳本，普通人則更在乎界面。
原則23：最好的產(chǎn)品應(yīng)當(dāng)不需要用戶手冊，用戶應(yīng)該一看就會用。
原則24：當(dāng)你無法在兩個選項(xiàng)之間做出決定時，請不要通過配置選項(xiàng)的方式來呈現(xiàn)問題。這會給用戶和架構(gòu)師帶來麻煩。對于系統(tǒng)如何運(yùn)作的細(xì)節(jié)，他們沒有你了解，他們怎么能做出決定呢？最好的方案是找到一個每次都有效的選擇；其次是自動做出選擇；第三個方案是添加配置參數(shù)并設(shè)置合理的默認(rèn)值。
原則25：始終具有合理的配置默認(rèn)值。
原則26：設(shè)計不良的配置會制造麻煩。始終配置幾個示例值。
原則27：詢問用戶配置值的時候，注意選擇用戶無需即可設(shè)置的值（例如，不要問用戶需要的最大緩存條目數(shù)量，而是要問他想要用于緩存的內(nèi)存數(shù)量）
原則28：如果發(fā)現(xiàn)未知配置，則拋出錯誤。永遠(yuǎn)不要忽視它。在調(diào)試過程中，無提示的配置錯誤會浪費(fèi)我們很多調(diào)試時間。
難點(diǎn)
原則29：嘗試新語言很容易，但要正確使用卻很難。除非公司愿意組建一個十人團(tuán)隊(duì)并花一年的時間來學(xué)習(xí)，否則盡量不要這樣做。如果你仍不死心，請閱讀有關(guān)語言設(shè)計的五個問題 后再做定奪。
原則30：可組合的拖放 UI 很難實(shí)現(xiàn)，除非團(tuán)隊(duì)準(zhǔn)備投入10人年的資源，否則不要去做。
最后，讓我談一些隨著時間的推移我的主意發(fā)生變化的事情。在理想情況下，一個平臺應(yīng)當(dāng)由多個組件組成，每個組件負(fù)責(zé)一個方面（例如，安全性、消息傳遞、注冊、調(diào)解、分析，等等）。使用這些功能構(gòu)建的系統(tǒng)將是最佳的。
不幸的是，嚴(yán)格執(zhí)行這一點(diǎn)可能是一個錯誤，特別是在新功能的初始狀態(tài)，其中簡單的功能可能導(dǎo)致大的變化，因?yàn)槲覀冊噲D使一切都是垂直的。有時我們發(fā)現(xiàn)我們添加的功能沒用，然后所有額外的工作都沒有用。最后，如果這需要多個團(tuán)隊(duì)之間的協(xié)商，該功能可能永遠(yuǎn)都無法完成。
現(xiàn)在來看，我愿意接受重復(fù)。治療帶來的結(jié)果可能會比疾病導(dǎo)致后果更嚴(yán)重。
結(jié)論
作為架構(gòu)師，我們應(yīng)該像園丁一樣思考、塑造、策劃和去除雜草而不是定義和構(gòu)建。
在短期內(nèi)，由一位架構(gòu)師來制定架構(gòu)的確既快捷又實(shí)惠。但是，從長遠(yuǎn)來看，團(tuán)隊(duì)的力量才是最強(qiáng)的。
如果你不夠投入和細(xì)心，你只指出錯誤，但是不道明錯誤原因，那么你的意見可能會讓團(tuán)隊(duì)感到困惑。避免這種情況的一種方法是擁有一套普遍接受的原則，這些原則是討論架構(gòu)時遵循的基本點(diǎn)，也是初學(xué)者學(xué)習(xí)架構(gòu)的好資源。
原文：https://hackernoon.com/first-do-no-harm-30-principles-that-helped-me-avoid-fly-by-architecture-reviews-e8952ac632a
作者：Srinath Perera ，是一位計算機(jī)科學(xué)家、軟件架構(gòu)師、作家，他是 apache 的核心成員，擁有 15 年分布式系統(tǒng)編程經(jīng)驗(yàn)，設(shè)計了 Apache Axis2 以及 WSO2 流處理器。
譯者：安翔，責(zé)編：胡巍巍
架構(gòu)師好文回顧
??牛逼的架構(gòu)師是怎么煉成的？
??李艷鵬：史上最全的架構(gòu)師圖譜
??架構(gòu)師，是否需要寫代碼
??架構(gòu)大咖言傳身教：從程序員到架構(gòu)師
??聽說過全棧工程師，那全棧架構(gòu)師又是什么鬼？
#專注技術(shù)人的成長#
總結(jié)
以上是生活随笔為你收集整理的30条架构原则：助你成为大牛架构师的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 万字长文剖析 APM 系统？如何设计与实
- 下一篇： NYOJ 662 汽水瓶