張泰峰?6月3日

寫在前面

2019悄悄溜走一半，無論是離別的憂愁，還是成長路途的艱辛，都在心中滾燙。

距離上一篇文章已經很久了... 懶惰的博主不能將這一切歸結于我的時間、我的規劃、我的工作，只能怪自己懶......正所謂學如逆水行舟，不進則退，不進到最后就只能退了。

今天突發一些關于架構的感悟，執筆記錄下來。

軟件架構的出發點

軟件架構是一個軟件系統開發生命周期中最前端的部分，也是最關鍵、最核心的部分。它決定了后續代碼的走向；能夠決定項目的走向；有時候甚至能夠決定一家公司的生死。軟件架構的成功要素，有很多點，這些點的一兩個或更多個，組成了不同級別的業務系統或用戶系統：

*1 可靠性

*2? 安全性

*3 可伸縮性

*4 可定制化

*5 可擴展性

*6 可維護性

*7 用戶體驗

*8 可快速迭代性

面向用戶的系統，用戶體驗 、快速迭代、安全、可靠?，這四點必不可少，這些點圍繞著的基礎的技術選型、管理模式、規則、流程，也就跟著對應的權重的不同去分配了。

假如公司A需要做一個工具app，xx計算器、或xx記事本。 想要獲得市場認可，它的架構就需要大約 ： 30%?用戶體驗 、20%快速迭代、 10%可靠。按照這個權重的分配去管理架構的技術選型、管理模式等等。一個工具app的安全性做的無懈可擊，是不會得到市場認可的；一個電商網站的安全性可靠性不能保證，會被市場所拋棄。

又假如公司B有一個對內的管理系統，想要正確的結果，首先就得保證 可快速迭代性?，業務每天都在變化，相反的用戶體驗、伸縮、安全、可靠，都可以相對不那么迫切。

通過可快速迭代性迅速迭代可定制化需求和可擴展性需求提升了用戶體驗，用戶體驗的提升帶動用戶量的增長，則對可靠性、可維護、安全性、可伸縮性提出了更高的要求。

上面是我想要表達的，軟件架構的出發點，是項目所處的市場的需求決定的。需求是什么，決定了架構是什么。

架構是難以更改的。是的，架構是非常難以更改的，如果你的項目已經推出市場了，除非重頭來過，承受徹底重構帶來的陣痛。這里往往要面臨更嚴峻的考驗，例如人事處理：有很多c++開發，想要轉java，或有很多php開發，想要轉python；再例如架構的改弦更張勢必要有加班的，埋頭苦干一個月，再走一遍來時的路~

舉個栗子：TDD ，TDD本質過程就是要貫穿從需求分析、設計、編碼、測試、整個研發過程。它其實是需求驅動，逐個滿足每個的需求。 TDD的核心就在于把需求分析,設計,質量控制量化的過程，在編寫測試用例時就可以規避、重構、設計需求的架構。TDD其實就是一個以需求驅動的架構模式、開發模式。

或許你已經在做相關的架構處理了，或許你已經吃到了一些苦頭，這個理論或許可以幫助你認識到，要根據市場需求來制定合適的架構，推導合適的架構細節。要慎重。既不可以過度設計，也不可以設計不足，這把量尺是：市場需求。

架構以人為本

架構設計必須要考慮人在其中的重要因素，合適的人做合適的事情。一個好的架構，首要的就是要考慮所在團隊的人的情況，我們往往傾向于抓技術層架構，忽略了怎么將合適的人放到合適的位置，已有的團隊人員能不能合理的在架構中發揮應該有的作用。

抽象的處理、框架的引進很重要的一點是，如何解決人員素質、想法、環境的不一致。框架通過封裝復雜的東西，簡化業務的復雜程度，讓對應的人能夠專注對應的事情。抽象通過可以被共同理解的概念，簡化復雜的內部處理邏輯，將人的目標聚攏在一起。

軟件架構應該以人為本，將最高效的人放在最高效的地方能夠取得最大化的成果，架構設計也就必須考慮人的因素。

例如我們有一個5人團隊做一個項目，團隊成員比例大約是： 1個leader? ， 2 個核心， 2個實習，在設計這個項目的架構的時候，你必須要考慮的是，如何設計能把2個核心成員的力量放在合適的地方，如何設計能讓2個實習成員能夠完成既定的任務。 假如將2個核心與2個實習放在一起看待，過不了多久會出現一個情況，核心成員感覺做的東西技術含量太低，實習成員可能感覺東西難、累、趕，長此以往，項目會頻繁面臨人員變更。

我們傾向于集中精力做技術層架構，而不是人員層架構方面工作的主要原因，不是因為技術更重要，而是因為技術更容易做。人際交往是很復雜的，并且就效果而言從來都不會是很明晰和清楚的，但是它們比工作的任何其他方面都更重要。寫代碼并非只是寫代碼而已，而是與人有關——需要理解的東西包括那些人是誰，他們能作出什么貢獻和需要什么東西，以及是多數派還是少數派等，諸如此類。“如果你把架構重點放一部分在人員安排的身上，那么就會發生更好的事情。

從人的角度衍生出的信息的交互

信息的交互其實是軟件開發過程中需要重點關注的事情。信息的完整性、真實性，影響著開發過程中風險的暴露。風險則決定了項目的成功與否，所以我認為它是架構其中的一部分，它常常被人忽略，因為它既不屬于技術，也不屬于人員，更像管理工作，但其實它也跟架構有明顯的關系。

軟件項目的風險無非體現在以下四個方面:需求、技術、成本和進度。任何信息的不對等都有可能導致需求完成有誤、技術設計偏離、成本過大、進度延遲。怎么樣規劃合理的信息交互、制定合理的反饋機制是架構需要考慮的問題之一。

總結和感悟

架構的目的是貼合市場需求指定合理的技術規劃、人員規劃、信息交互規劃，架構是不僅僅局限于技術層面的。一個軟件架構師，你需要統籌全局，深入了解需求，了解業務的走向，了解技術的價值所在。也需要制定或迎合人員的搭配，制定信息交互的流程。

核心觀點

就是不可以忽略市場需求在架構設計中的力量，

更不可以忽略人在架構處理中所占的比例大小。

過度關注技術本身是一個本末倒置的行為。

閱讀目錄（置頂)(長期更新計算機領域知識）https://blog.csdn.net/weixin_43392489/article/details/102380691

閱讀目錄（置頂)(長期更新計算機領域知識）https://blog.csdn.net/weixin_43392489/article/details/102380882

閱讀目錄（置頂)(長期科技領域知識）https://blog.csdn.net/weixin_43392489/article/details/102600114

總結

以上是生活随笔為你收集整理的第六十六期:软件架构之道的一次感悟的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。