如何度量軟件架構(gòu)丨IDCF
來源：碼猿外 作者：麻廣廣
1. 為什么要度量軟件架構(gòu)
不管是軟件架構(gòu)治理，還是研發(fā)效能治理，通過有效的指標度量都能協(xié)助找到問題并加以改進，指標也能反映改進后的效果。
指標很神奇，它就像是一個開關(guān)，如果你關(guān)注它，開關(guān)啟動，可能會看到一些奇怪的反應(yīng)。找到合適的指標讓系統(tǒng)達到自己預(yù)期的效果，非常難。然而，這并不意味著我們要放棄通過指標度量的手段來解決問題。
通過指標來識別軟件架構(gòu)問題，就像醫(yī)生依據(jù)檢查報告上的指標診斷病人的病情一樣。軟件系統(tǒng)的運行可能遠不及人體那么復雜，但隨著系統(tǒng)規(guī)模的增大，系統(tǒng)的復雜度會遠超一個人所能認知的范圍，在這種情況下，很難通過架構(gòu)師的經(jīng)驗來判斷哪里有問題，像醫(yī)生一樣通過一些關(guān)鍵指標來找到問題無疑是更明智的選擇。
醫(yī)學發(fā)展到今天，病情診斷過程很多已經(jīng)流程化，患者到醫(yī)院說出疾病表現(xiàn)，醫(yī)生就知道該做哪些檢查，通過各種維度的“指標”數(shù)據(jù)來判斷真實的病因。有些關(guān)鍵指標甚至能夠直接幫助醫(yī)生確診疾病，比如針對新冠肺炎的核酸檢測。
如果你無法度量它，你就無法管理它?！?彼得·德魯克
軟件系統(tǒng)的維護者就像是醫(yī)生，指標度量的重要性不言而喻，一方面可以通過度量找到系統(tǒng)架構(gòu)的問題，另一方面也可以通過度量，來指導改進并觀察改進效果。
2. 評價軟件架構(gòu)需要度量什么
Mamdouh Alenezi在論文《Software Architecture Quality Measurement Stability and Understandability》中整理了一些軟件架構(gòu)衡量標準和顆粒度定義，參見下表：
圖片來源于論文《Software Architecture Quality Measurement Stability and Understandability》
圖中給出的顆粒度包括包/類/方法，組件/庫，架構(gòu)三大類，我在之前的文章 《架構(gòu)優(yōu)化方向》[1] 中，將架構(gòu)優(yōu)化分為四個大的方向：代碼實現(xiàn)、組件設(shè)計、架構(gòu)設(shè)計和基礎(chǔ)設(shè)施，在上面論文顆粒度的基礎(chǔ)上增加的基礎(chǔ)設(shè)施方向，目的是在靜態(tài)代碼和架構(gòu)設(shè)計的基礎(chǔ)上，增加對運行時狀態(tài)的補充。
這四個維度涵蓋了軟件系統(tǒng)的頂層架構(gòu)設(shè)計，到實際落地的代碼質(zhì)量，以及軟件系統(tǒng)的運行時環(huán)境，從這四個維度入手進行優(yōu)化，相信可以解決軟件架構(gòu)的大部分問題。
3. 通過哪些指標度量軟件架構(gòu)
然而，值得強調(diào)的是，給出一套度量標準用來衡量所有的軟件架構(gòu)是不切實際的。正如 ISO/IEC 25010 - Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models[2] 中提到：
It is not practically possible to specify or measure all subcharacteristics for all parts of a large computer system or software product. The relative importance of quality characteristics will depend on the high-level goals and objectives for the project.
這兩句話放到10年后的今天依然成立，軟件開發(fā)中沒有銀彈，不可能找到適合所有軟件架構(gòu)的度量方法和標準，從上文中《Software Architecture Quality Measurement Stability and Understandability》Table I 可見一斑，每篇論文給出的指標都不相同。在實際的軟件架構(gòu)設(shè)計和演進過程中，因業(yè)務(wù)場景不同，每個軟件系統(tǒng)的架構(gòu)關(guān)注點是不同的，設(shè)計目標也不同，自然對架構(gòu)質(zhì)量要求的重點就不同。
因此，在實際軟件架構(gòu)治理過程中，需要針對軟件架構(gòu)的特點，以及當前的問題，選擇合適的度量指標來指導優(yōu)化。下面就從代碼實現(xiàn)，組件設(shè)計，架構(gòu)設(shè)計和基礎(chǔ)設(shè)施四個維度給出一些可以參考的指標，以及每個指標能夠幫助識別哪些問題，進而通過這些指標找到提升軟件架構(gòu)健康度的方法。
3.1代碼實現(xiàn)相關(guān)指標
說到代碼實現(xiàn)，大家一定會想到《Clean Code》以及《重構(gòu)》，結(jié)合一些常用代碼檢查工具規(guī)則的定義，列舉了一些常見的代碼實現(xiàn)層面相關(guān)指標：
| 指標 | 計算方法 | 指標說明 |
| 圈復雜度 | 參考PMD: 圈復雜度 | 圈復雜度用來評估函數(shù)的復雜度，如果函數(shù)圈復雜度過高，表明函數(shù)有太多的決策變量，邏輯拆分不夠，難以理解和維護 |
| 超大類占比 | 超大類數(shù)量/代碼總量 | 超大類處理太多業(yè)務(wù)，職責不單一，業(yè)務(wù)耦合嚴重，不利于擴展和維護 |
| 超大函數(shù)占比 | 超大函數(shù)數(shù)量/代碼總量 | 同上 |
| 重復代碼頻率 | 重復代碼段發(fā)生次數(shù) | 重復代碼會讓相同邏輯散落在不同的代碼中，維護困難，容易產(chǎn)生修改過程中漏掉一部分導致問題 |
| 循環(huán)訪問進程外組件頻率 | 在循環(huán)中調(diào)用數(shù)據(jù)庫或三方系統(tǒng)API的發(fā)生頻率 | 循環(huán)訪問進程外組件會引發(fā)性能問題 |
| 測試覆蓋率 | 測試覆蓋率 | 測試覆蓋率不足，缺少對既有代碼的保護，修改很難保證不影響之前的功能 |
3.2組件設(shè)計相關(guān)指標
在組件自身設(shè)計上，也要遵循開發(fā)團隊約定的設(shè)計原則，比如分層架構(gòu)每層的職責，以及層與層之間的依賴關(guān)系。組件設(shè)計相關(guān)指標關(guān)注組件內(nèi)部結(jié)構(gòu)設(shè)計的合理性，以及一些交互機制的規(guī)范性，常用的指標如下：
| 指標 | 計算方法 | 指標說明 |
| 循環(huán)依賴[3]數(shù)量 | 類之間循環(huán)依賴次數(shù) | 循環(huán)依賴打破了單向依賴原則，很難判斷修改產(chǎn)生的影響。一旦出問題，非常難定位問題 |
| 類穩(wěn)定性 | 參見Bob大叔《敏捷軟件開發(fā)：原則、模式與實踐》第20章 包的設(shè)計原則 | 穩(wěn)定性是指改變的難易程度，對于希望類足夠穩(wěn)定的類，要控制依賴其他類的次數(shù)，提高被依賴的次數(shù)。穩(wěn)定性應(yīng)該順著類依賴的方向遞增 |
| 依賴異常數(shù)量 | 進程內(nèi)模塊分層依賴關(guān)系錯誤的次數(shù) | 同循環(huán)依賴 |
| 組件間重復代碼頻率 | 公共功能代碼重復發(fā)生次數(shù) | 對于一些公共功能，沒有抽象組件，復制粘貼代碼，維護難度大 |
3.3架構(gòu)設(shè)計相關(guān)指標
架構(gòu)設(shè)計相關(guān)指標關(guān)注組件之間的邊界，交互關(guān)系的規(guī)范性，常見指標如下：
| 指標 | 計算方法 | 指標說明 |
| 組件循環(huán)依賴數(shù)量 | 組件之間循環(huán)依賴次數(shù) | 組件間依賴關(guān)系混亂，職責不清 |
| 組件職責偏差率 | 組件職責與業(yè)務(wù)建模結(jié)果之間的偏差率 | 組件沒有按業(yè)務(wù)合理劃分，導致組件間關(guān)系復雜 |
| 組件穩(wěn)定性 | 參見類穩(wěn)定性 | 參見類穩(wěn)定性說明 |
| 調(diào)用鏈長度 | 接口在多個組件間流轉(zhuǎn)的次數(shù) | 調(diào)用鏈越長，組件間依賴深度越大，依賴關(guān)系越復雜，排查問題越難 |
3.4基礎(chǔ)設(shè)施（運行時）相關(guān)指標
基礎(chǔ)設(shè)施（運行時）相關(guān)指標從軟件系統(tǒng)的運行時觀測軟件架構(gòu)的健康度，從外在表現(xiàn)上找到系統(tǒng)的脆弱點，常見指標如下：
| 指標 | 計算方法 | 指標說明 |
| 基礎(chǔ)設(shè)施負載率 | 基礎(chǔ)設(shè)施資源，數(shù)據(jù)庫，緩存的使用量 | 衡量當前系統(tǒng)是否到了瓶頸，能否應(yīng)對突發(fā)的峰值請求 |
| 平均響應(yīng)時間 | 生產(chǎn)環(huán)境API的平均響應(yīng)時間 | 衡量軟件架構(gòu)的性能 |
| 系統(tǒng)可用性[4] | 系統(tǒng)在線可用的時間占比 | 衡量架構(gòu)的穩(wěn)定性和整體質(zhì)量 |
| 平均故障恢復時長 | 故障發(fā)生后恢復可用的平均時長 | 衡量架構(gòu)在應(yīng)對突發(fā)問題時快速恢復的能力 |
| 數(shù)據(jù)不一致[5]問題占比 | 數(shù)據(jù)不一致問題占所有問題的比例 | 數(shù)據(jù)不一致通常是因為架構(gòu)設(shè)計不合理，或組件交互方式不合理導致的 |
| 無用功能占比 | 生產(chǎn)環(huán)境長期不使用功能的占比 | API或者某些功能長期不使用需要盡快清理，降低認知負載，也有助于優(yōu)化組件之間的關(guān)系 |
4. 度量之外
指標度量對于軟件架構(gòu)治理很重要，就像文章開頭的隱喻，醫(yī)生要看到各種檢查指標的結(jié)果才能給出診斷，沒有這些指標，大部分醫(yī)生是沒法坐診的。然而，醫(yī)生出具診斷時，指標只是作為參考，醫(yī)生的專業(yè)知識和經(jīng)驗在診斷過程中起到至關(guān)重要的作用，也有常見的情況是指標異常，但醫(yī)生仍然會說，不是什么大問題，定期復查，多運動，注意飲食。
除了可度量的指標，實際軟件架構(gòu)治理的過程中，也會有很多不可度量且非常重要的指標。就像行軍打仗，能打硬仗的隊伍不一定所有的指標都好看，但不妨礙它的戰(zhàn)績。因此，指標度量的要點是幫助開發(fā)團隊更好地理解系統(tǒng)，理解架構(gòu)，找到問題，設(shè)計解決方案，不斷優(yōu)化以達到軟件架構(gòu)治理的目標，切不可為了指標而度量。
References
[1] 《架構(gòu)優(yōu)化方向》: https://www.maguangguang.xyz/architecture-optimization-topics
[2] ISO/IEC 25010 - Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models: https://www.iso.org/standard/35733.html
[3] 循環(huán)依賴: https://www.maguangguang.xyz/eliminate-cyclic-dependency
[4] 系統(tǒng)可用性: https://www.maguangguang.xyz/how-to-improve-system-availability
[5] 數(shù)據(jù)不一致: https://www.maguangguang.xyz/data-consistency
2022年首場將在美麗的海濱城市-大連舉辦，8月6-7日，36小時內(nèi)從0到1打造并發(fā)布一款產(chǎn)品。
企業(yè)組隊參賽&個人參賽均可，趕緊上車~??
