1 背景

隨著需求開發迭代，程式碼庫規模逐漸變大，新的團隊成員引入等諸多因素，系統起初制定的架構規則不可避免遭到破壞。不僅僅是破壞團隊的統一開發規範，更為重要的是隨著程式碼庫規模逐漸增長，大大降低系統的可維護性、擴充套件性，增加評審複雜度和重構成本，也最終導致團隊生產力下降以及研發成本增長。

在敏捷開發環境下，系統透過迭代增量的交付價值，系統架構也是如此。團隊不可能在專案之初就建立完美的系統架構，系統架構應該隨著系統迭代不斷演進。

架構演進和架構腐化是看待架構的不同視角：架構腐化著眼於現狀，架構演進側重於未來

架構腐化不可避免，隨著時間流轉腐化現象必然發生。而我們需要做的是：透過某種方式及早發現和修正

2 為什麼選擇Archunit

我們需要透過引入一種機制或技術，降低或及早發現架構腐化現象的發生，保持統一的系統架構約束。

• 支援架構規則自動化檢查
• 輕量級，接入成本低
• 結果及時反饋
• 靈活擴充套件且擴充套件成本低

對於架構規則常見的驗證方式：程式碼評審、程式碼質量分析工具或平臺、Archunit

以下對常見的幾種方式進行優劣勢對比：

程式碼評審：透過強流程控制程式碼評審活動發生，增強程式碼評審的強度和質量

優勢

• 不需要引入額外的技術，沒有學習成本
• 靈活：透過人工評審方式可以覆蓋架構約束更全面

劣勢

• 非自動化方式執行，質量靠人工保證，人為因素存在較多不可控因素
• 程式碼評審範圍越廣，人力成本投入則越大
• 程式碼評審流程後置，不能及時反饋規則檢測結果

程式碼質量分析工具：比如Sonar、Checkstyle等

優勢

• 成熟的工具或平臺，內建開箱即用的規則
• 三方工具支援，不影響程式碼庫結構

劣勢

• 缺少靈活性，架構規則約束支援程度有限，不能很好的解決架構層面規則約束
• 強調程式碼質量分析結果，不能有效處理強制規則約束
• 定製規則有一定成本(因平臺擴充套件能力而異)

Archunit：透過單元測試形式對架構規則自動化檢查

優勢

• 支援豐富的架構約束規則定製能力，例如分層依賴規則、包依賴規則、迴圈依賴、繼承關係約束等
• 雖然以單測程式碼方式體現，但不影響主業務開發，可以透過增量方式引入，逐步增強應用的架構約束能力
• Archunit 提供的Java 流式API 易於理解，接入和使用成本低
• 使用純Java單測框架以單元測試形式自動化執行，及時反饋單測結果

劣勢

• 需要額外編寫單元測試程式碼，增加了一部分工作量
• 引入了新的類庫有一定學習成本

3 Archunit是什麼

ArchUnit是一款免費、簡單可擴充套件的類庫，它可以使用任何Java單元測試框架來檢查Java程式碼的架構約束。基於Archunit我們可以自動化檢測：

• 迴圈依賴
• 包的包含關係
• 類的依賴關係
• 類和包的包含關係
• 繼承關係
• 註解

Archunit和程式碼質量分析工具的關係如下圖所示，二者都可以對程式碼進行分析，在功能覆蓋上存在一定交叉。

Archunit不能解決所有的架構屬性的約束自動化驗證，其主要側重於系統的演進性、可維護性、可測試性、可解釋性等，也可以對耦合度、命名規範等進行驗證。

4 引入Archunit

4.1 開始就是如此簡單

使用Archunit編寫架構規則約束非常簡單，其提供了便捷的流式API，可以快速的構建規則。

示例1：RULE.01 所有的列舉類必須以Enum為字尾

示例2：對應用分層進行約束校驗

在IDE下執行Archiunit單元測試結果示意如下圖所示：

4.2 如何組織架構規則

架構規則組織可以從多個維度，比如：

下圖左側所示：基於邏輯分類對規則進行分組

下圖右側所示：基於職能分類對規則進行分組

4.3 團隊如何規範化

團隊是否要引入Archunit本身也是一項架構決策，建議採用文件化形式對該決策進行記錄，記錄形式參考 《 輕量級架構決策記錄機制 》

如果團隊想要引入Archunit，從流程化和規範化視角可以基於準備-試點-最佳化-推廣的模式進行實施：

實施準備：

• 從規範複用的角度考慮，團隊需要定義統一的開發規範，包括但不限於編碼規範、異常規範、命名規範、依賴規範等等，並在團隊內達成一致。建議採用統一的、文件化的形式進行記錄(比如，線上表格系統)。對於每條開發規則建議增加比如 “正例”、“反例”、“規則描述”、“規則詳細說明”、“是否可自動實現” 等維度描述資訊
• 基於Archunit實現通用架構約束以便在不同專案間進行複用

應用試點：在產品線內部選定一個試點應用

覆盤最佳化：基於試點效果進行復盤，基於團隊成員反饋進行架構規則最佳化、已有規則的修改及廢棄等等

推廣普及：基於試點的一些實踐在其它應用或業務線進行推廣普及

對於遺留系統已經形成了特定的規則(有可能是已經發生腐化)，由於業務系統的持續迭代，在單個迭代完全大規模重構已有系統的可能性不大。所以，建議採增量方式，在迭代研發資源可接受的範圍內，逐步引入並豐富架構規則，並對破壞規則的應用程式碼進行重構。

5 結語

Archunit不能做什麼：

• 處理檔案
• 測試所有架構屬性
• 只支援JVM語言
• SOURCE註解
• 需要匯入大量程式碼，加入CICD流水線後的時長影響
• 不能保證自身的維護性

Archunit對架構約束的自動化檢測極有價值，且具有較低的接入和定製化成本，強烈建議團隊引入試點。引入Archunit進行架構約束自動化檢查後，將對以下方面產生影響：

• 有助於降低系統架構腐化，提升系統可維護性
• 新類庫引入有一定的學習成本
• 代碼評審活動增加一項活動：執行架構約束單元測試
• 開發成員日常開發中需要持續執行並關注架構約束單測結果，並確保測試透過