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進行架構約束自動化檢查后，將對以下方面產生影響：
- 有助于降低系統架構腐化，提升系統可維護性
- 新類別庫引入有一定的學習成本
- 代碼評審活動增加一項活動：執行架構約束單元測驗
- 開發成員日常開發中需要持續執行并關注架構約束單測結果，并確保測驗通過
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/509099.html
標籤：架構設計
上一篇：新消費時代，零售業的進與退？
下一篇：聊聊秒殺系統的設計（三）