大家是不是經(jīng)常聽人提到架構(gòu)，朦朧中也會覺得這是個好東西，可落實到現(xiàn)實中，架構(gòu)到底是個什么玩意兒？看個書又弄的高大上，錯綜復(fù)雜，忙繞無頭緒。用大白話，用通俗方式，講述簡單而深刻的道理，便是我的方向。
管理學(xué)上有個名詞，結(jié)構(gòu)效率遠(yuǎn)遠(yuǎn)優(yōu)于運營效率。
例如：一個大設(shè)備的生產(chǎn)，有10道工序（假設(shè)工序用時是均勻的），1人完整的裝配完1臺需要1天（10h小時），10人1天里每人裝了1臺，在每道工序上耗費的時間為1h。該人每天每道工序的裝配水平就是1h的水平。他每天多加1h班在某道工序上，也不過在該道工序上是2h的水平。
現(xiàn)在改成流水線作業(yè)，10個人每人負(fù)責(zé)一道工序，10個人一起完成這一天總共10臺的工作，這樣1人1天（10h）對負(fù)責(zé)的工序重復(fù)了10次，試想一下，一個人一天在一道工序上重復(fù)了10遍和做了1遍相比，哪個更熟練效率更高？后者不用加班，每天就是10h的熟練程度。
前者靠加班提升，這是運營效率；后者靠分工的組織架構(gòu)提升，這是結(jié)構(gòu)效率。
另一個例子，一鍋爐溫度監(jiān)測軟件，在一個大程序架構(gòu)里，A、B、C三位工程師均會用到溫度參數(shù)，分別根據(jù)測量結(jié)果用于調(diào)節(jié)通風(fēng)、送煤、報警。于是ABC分別各自編寫了這幾行并不復(fù)雜的程序。
A調(diào)試時，遇到了測量結(jié)果偶超出100度的問題，于是加了上下限判斷干擾數(shù)據(jù)丟棄處理；
B調(diào)試時，遇到了前后兩個測量時間相隔幾秒但溫度卻差別很大，水溫不應(yīng)該出現(xiàn)的干擾情況，于是B加了溫度變化率的判錯功能。
C調(diào)試時，發(fā)現(xiàn)了一個50Hz工頻干擾，于是加了50Hz陷波搞定。
圖1
如上編程的話，三個人各有各的經(jīng)驗，卻相互之間不能共享，當(dāng)?shù)搅擞脩衄F(xiàn)場后，萬一A遇到了B、C的問題，而A的代碼里沒有相應(yīng)措施，是不是會帶來召回或維修？通過ABC三人之間的交流來彌補各自的欠缺，管理效率上是不是也會有較大的漏洞？
如果將此軟件架構(gòu)改成圖2的形式，單獨設(shè)置ADC（）函數(shù)，A、B、C三位工程師分別調(diào)用該函數(shù)的功能，A發(fā)現(xiàn)超限，則反饋給ADC函數(shù)的編程人員，將上下限判斷的功能加入ADC（）；B將溫度變化率的判錯功能、C將數(shù)字濾波的功能也都加入函數(shù)ADC（）。這樣ABC三人的代碼，每個人是不是都享受到了三個人的經(jīng)驗？
圖2
再例如：一個硬件的大系統(tǒng)，外圍有諸多的功能，中央控制單元用一個大型的MCU實現(xiàn)調(diào)度和控制（圖3左圖），可想而知，各個部分之間的時序分配、中斷的交叉，對硬件設(shè)計師和軟件設(shè)計師會有多少邏輯上的復(fù)雜需求；
改變一下思路，換成圖3右圖的架構(gòu)方式，能獨立出去的終端功能用獨立的小型MCU實現(xiàn)，用一種“分散、自治、多元化”的設(shè)計思想，將一個強力中央單元的功能分散到諸多個諸侯國去，中央單元僅實現(xiàn)各部分之間的調(diào)度，將數(shù)據(jù)處理功能有各自單元獨立完成。試想一下，軟件調(diào)度邏輯和每部分的硬件難度是否可以大大降低。一個不太方便明說的示例，就是中美領(lǐng)導(dǎo)架構(gòu)的對比，我們國家的高層領(lǐng)導(dǎo)的工作難度就比美國要難得多，原因是大事小情都得上面操心，而美國，聯(lián)邦是聯(lián)邦，各州是各州，分散了。是否與此同理？
圖3
類似的事兒還有很多，比如DCDC電源種類的選擇（并不是歸一化就真的好）、晶振頻率的選擇、結(jié)構(gòu)布局等等，從架構(gòu)的角度去考慮設(shè)計方案，甚至有可能會顛覆曾經(jīng)一直以為是宇宙絕對真理的三觀。
架構(gòu)的改善，帶來的將是質(zhì)的提升。但架構(gòu)卻又是一個“好人不愿干，差人干不好”，“干好了沒人知道，干壞了也沒人知道”的事兒，當(dāng)然更多的是，做架構(gòu)設(shè)計的人、被差的架構(gòu)禍害的人，被好的架構(gòu)蔭庇的人，好多都還沒意識到架構(gòu)的價值和方法。
京公網(wǎng)安備11010802046783號
