作者：京東科技 倪新明

在敏捷開發環境下，系統通過迭代增量的交付價值，系統架構也是如此。團隊不可能在專案之初就建立完美的系統架構，系統架構應該隨著系統迭代不斷演進。架構演進和架構腐化是看待架構的不同視角：架構腐化著眼於現狀，架構演進側重於未來架構腐化不可避免，隨著時間流轉腐化現象必然發生。而我們需要做的是：通過某種方式及早發現和修正

1 面臨的問題

把目光從宏觀的演進和腐化視角聚焦在更加具體的問題和挑戰層面，作為團隊負責人或架構師，你是否面臨以下問題：

•團隊已經制定的開發規範很難持續性的落地，並在應用中保持較高的健康狀態

•系統制定的架構決策在系統迭代過程中逐漸弱化、打破，甚至隨著時間的推移，團隊中已經沒有人關注決策的落地和遵守情況

•歷史的架構決策早已 」無跡可尋「，更何談對系統架構演進的追溯

•如何快速的判斷當前系統腐化程度或健康情況？

•不論是架構升級、系統演進，系統缺失指導性的自動化約束，確保演進方向不會偏離

基於以上的問題，我相信團隊都會做過一些實踐，不管是流程的強約束，還是系統的自動化，都嘗試解決如上所面臨的所有或部分問題。典型的方式：

•方式一：程式碼評審(強流程)

•方式二：靜態分析工具，並結合CICD流水線

•方式三：基於ArchUnit的架構約束單元測試實踐

1.1 程式碼評審

程式碼評審是最典型的方式，對每次迭代的程式碼交付進行強流程的評審，通過多幹系人蔘與，可以靈活的、深入的評估實現對於約束的遵守情況。當然，評審越完備，需評審人員投入的精力和時間成本越大。

大量的開發實踐表明，系統無法持續保持高強度的、完備的程式碼評審，評審的力度會由於各種因素而下降，最終導致系統的腐化，這種人為不可控因素是程式碼評審的主要問題。

另外一個問題是，程式碼評審在研發流程中的後置性。一般情況下，程式碼評審介入的實際可能是在開發提測之後，聯調結束之前，當然有些團隊可能更後置。流程越後置，如果存在大規模的架構約束破壞，則可能導致重構成本與專案週期的衝突。

1.2 靜態分析工具

程式碼的靜態分析工具比較多，比如CheckStyle 、FindBug、Sonar，公司內部的EOS等等，這些靜態分析工具能夠對程式碼的規範，比如註釋、命名、可能存在潛在缺陷的程式碼段、圈複雜度等進行分析。

靜態分析工具的最大優勢在於：

•平臺化支援，豐富的產品矩陣：比如既有面客的PC端平臺，又有方面研發使用的IDE外掛等等

•校驗的自動化執行能力：可以通過平臺、IDE外掛工具或是流水線（如果整合CICD）觸發自動化執行並生成分析報告。

靜態分析工具的不足主要表現在：

•一般情況下，這些工具僅僅是提供建議的掃描報告，不具強流程控制，在約束打破時不會阻斷應用構建。部分工具（並不是所有）與CICD流水線進行了打通，通過質量門禁來干預構建流程，一定程度上能作為系統約束校驗的最後卡點。

•靜態分析工具的能力側重點一般在於開發編碼規範的約束，比如命名、註釋、程式碼段規約等等，而對於高層的架構約束的校驗較弱，比如分層架構約束、」元件「間約束、類位置約束、包與類的包含關係約束等等。

•約束執行的粒度更傾向於統一規範，比如在團隊維度、程式語言維度，而實際上忽略了應用級的客製化化約束。不同的應用工程具備特定的應用架構風格，基於特定風格下有不同的架構約束。這些差異化規劃與團隊統一規則存在潛在衝突，並不一定在跨應用下都適用。

1.3 基於ArchUnit

ArchUnit是一個基於Junit執行的架構約束類庫，其能夠通過單元測試的形式對系統架構約束進行自動化的校驗。團隊引入ArchUnit的成本並不高，由於是基於單元測試形式引入，並不影響應用程式的主線流程。團隊在引入往往有集中形式：

•單個應用引入，每個應用都定義各自的單測

•公共jar包，多應用複用

上述應用模式也同樣在統一規範和應用差異化層面存在類似的問題。

1.4 共性問題

以上的三種實踐方案存在以下幾個共性問題無法解決：

•團隊統一規範和應用級別的客製化化支援

•架構決策記錄的管控與追蹤

•多維度的架構指標分析

2 ArchKeeper 平臺建設的核心目標

基於對已有問題及解決方案的分析，我們希望平臺化的解決方案，ArchKeeper平臺建設的核心目標如下：

•架構約束自動化測試能力：支援架構約束的自動化執行

•靈活、簡單的規則擴充套件能力：規則的客製化擴充套件應儘量保持簡單、靈活，滿足實際的客製化化需求

•團隊統一規範與應用擴充套件規則的統一執行

•結果及時反饋，支援與CICD流水線整合：自動化執行前置到開發階段，並通過CICD流水線作為最後卡點

•ADR管控與追蹤：以產品線和應用為載體，對系統的架構決策進行統一管控，並具備ADR的視覺化追溯能力

•架構約束靜態分析模式，以評估架構腐化：基於程式碼倉庫及規則庫的靜態分析能力，以提供高層的應用規則分析報表

•多維度架構治理指標分析能力：對應用提供更多維度的指標分析，比如元件耦合度等，為架構演進提供指引

3 ArchKeeper 核心理念

理念一：架構約束是強制規則，應用必須遵守，否則應阻斷應用構建

系統的架構決策是影響系統的「重要」的東西，決策評審通過之後應確保應用的遵循，團隊應該評估校驗決策執行的方式，比如哪些可以自動化校驗，哪些需要基於人工審查。對於支援自動化校驗的架構約束，應用必須遵守，不能破壞約束限制。因此，如果存在破壞約束情況，應當阻斷應用構建。

理念二：架構約束測試的執行應該儘量前置，及時反饋

流程後置帶來的問題就是如果存在架構約束的破壞，研發進行重構需要一定時間成本。流程越後置，重構成本越高。因此，架構約束的自動化執行應該儘量前置，提前至開發階段，並儘可能的及時反饋校驗結果以提升效率。

理念三：架構約束無法完全統一，在團隊統一規範之外，允許應用級的客製化，且須統一執行

架構約束的範圍比較廣，團隊無法形成完全統一的、標準一致的約束規範。有些約束是團隊層面的，比如編碼規範中的某些強制約束。而有些則是應用級別的，比如特定應用下的分層約束等等。因此，這種客製化化是必然存在的。雖然，團隊統一約束和應用級別的客製化化約束無法完全統一，但二者應該在統一的自動化流程中執行。

理念四：系統的架構決策記錄應當留存並可追溯

系統的架構決策記錄（ADR）是團隊的重要資產，ADR應該以檔案化形式留存，並能夠對ADR的演進提供追溯能力。

理念五：多維度的架構指標分析有利於防止架構腐化，為架構演進提供指引

ArchKeeper平臺之所以計劃提供多維度架構指標的分析能力正是基於這樣一個前提理念：對應用進行多維度的架構指標分析，有利於觀測系統的腐化情況，併為系統的架構演進提供一定的指引。

4 結語

文章主要闡述了研發中存在的問題及ArchKeeper平臺化建設理念及目標，並沒有涉及具體的實現。後續的系列文章會對ArchKeeper能力規劃、設計實現(基於DDD)進行持續的分享交流。

關聯文章：

《 通過自動化單元測試的形式守護系統架構 》

《 輕量級的架構決策記錄機制 》