寫在前面

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個實習放在一起看待，過不了多久會出現一個情況，核心成員感覺做的東西技術含量太低，實習成員可能感覺東西難、累、趕，長此以往，專案會頻繁面臨人員變更。

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

從人的角度衍生出的資訊的互動

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

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

總結和感悟

       架構的目的是貼合市場需求指定合理的技術規劃、人員規劃、資訊互動規劃，架構是不僅僅侷限於技術層面的。一個軟體架構師，你需要統籌全域性，深入瞭解需求，瞭解業務的走向，瞭解技術的價值所在。也需要制定或迎合人員的搭配，制定資訊互動的流程。

       這是我現階段比較深刻的感悟，執筆記錄，也是最近吃的教訓的結果。我的觀點不一定正確，感謝大家觀看，如有疑問，歡迎留