張?zhí)┓?6月3日

寫在前面

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

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

今天突發(fā)一些關(guān)于架構(gòu)的感悟，執(zhí)筆記錄下來。

軟件架構(gòu)的出發(fā)點

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

*1 可靠性

*2? 安全性

*3 可伸縮性

*4 可定制化

*5 可擴(kuò)展性

*6 可維護(hù)性

*7 用戶體驗

*8 可快速迭代性

面向用戶的系統(tǒng)，用戶體驗 、快速迭代、安全、可靠?，這四點必不可少，這些點圍繞著的基礎(chǔ)的技術(shù)選型、管理模式、規(guī)則、流程，也就跟著對應(yīng)的權(quán)重的不同去分配了。

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

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

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

上面是我想要表達(dá)的，軟件架構(gòu)的出發(fā)點，是項目所處的市場的需求決定的。需求是什么，決定了架構(gòu)是什么。

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

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

或許你已經(jīng)在做相關(guān)的架構(gòu)處理了，或許你已經(jīng)吃到了一些苦頭，這個理論或許可以幫助你認(rèn)識到，要根據(jù)市場需求來制定合適的架構(gòu)，推導(dǎo)合適的架構(gòu)細(xì)節(jié)。要慎重。既不可以過度設(shè)計，也不可以設(shè)計不足，這把量尺是：市場需求。

架構(gòu)以人為本

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

抽象的處理、框架的引進(jìn)很重要的一點是，如何解決人員素質(zhì)、想法、環(huán)境的不一致。框架通過封裝復(fù)雜的東西，簡化業(yè)務(wù)的復(fù)雜程度，讓對應(yīng)的人能夠?qū)Ｗ?yīng)的事情。抽象通過可以被共同理解的概念，簡化復(fù)雜的內(nèi)部處理邏輯，將人的目標(biāo)聚攏在一起。

軟件架構(gòu)應(yīng)該以人為本，將最高效的人放在最高效的地方能夠取得最大化的成果，架構(gòu)設(shè)計也就必須考慮人的因素。

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

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

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

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

軟件項目的風(fēng)險無非體現(xiàn)在以下四個方面:需求、技術(shù)、成本和進(jìn)度。任何信息的不對等都有可能導(dǎo)致需求完成有誤、技術(shù)設(shè)計偏離、成本過大、進(jìn)度延遲。怎么樣規(guī)劃合理的信息交互、制定合理的反饋機制是架構(gòu)需要考慮的問題之一。

總結(jié)和感悟

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

核心觀點

就是不可以忽略市場需求在架構(gòu)設(shè)計中的力量，

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

過度關(guān)注技術(shù)本身是一個本末倒置的行為。

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

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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。