在敏捷开发环境下，系统通过迭代增量的交付价值，系统架构也是如此。团队不可能在项目之初就建立完美的系统架构，系统架构应该随着系统迭代不断演进。架构演进和架构腐化是看待架构的不同视角：架构腐化着眼于现状，架构演进侧重于未来架构腐化不可避免，随着时间流转腐化现象必然发生。而我们需要做的是：通过某种方式及早发现和修正

1 面临的问题

把目光从宏观的演进和腐化视角聚焦在更加具体的问题和挑战层面，作为团队负责人或架构师，你是否面临以下问题：

团队已经制定的开发规范很难持续性的落地，并在应用中保持较高的健康状态
系统制定的架构决策在系统迭代过程中逐渐弱化、打破，甚至随着时间的推移，团队中已经没有人关注决策的落地和遵守情况
历史的架构决策早已 ”无迹可寻“，更何谈对系统架构演进的追溯
如何快速的判断当前系统腐化程度或健康情况？
不论是架构升级、系统演进，系统缺失指导性的自动化约束，确保演进方向不会偏离

基于以上的问题，我相信团队都会做过一些实践，不管是流程的强约束，还是系统的自动化，都尝试解决如上所面临的所有或部分问题。典型的方式：

方式一：代码评审(强流程)
方式二：静态分析工具，并结合CICD流水线
方式三：基于ArchUnit的架构约束单元测试实践

1.1 代码评审

代码评审是最典型的方式，对每次迭代的代码交付进行强流程的评审，通过多干系人参与，可以灵活的、深入的评估实现对于约束的遵守情况。当然，评审越完备，需评审人员投入的精力和时间成本越大。

大量的开发实践表明，系统无法持续保持高强度的、完备的代码评审，评审的力度会由于各种因素而下降，最终导致系统的腐化，这种人为不可控因素是代码评审的主要问题。

另外一个问题是，代码评审在研发流程中的后置性。一般情况下，代码评审介入的实际可能是在开发提测之后，联调结束之前，当然有些团队可能更后置。流程越后置，如果存在大规模的架构约束破坏，则可能导致重构成本与项目周期的冲突。

1.2 静态分析工具

代码的静态分析工具比较多，比如CheckStyle 、FindBug、Sonar，公司内部的EOS等等，这些静态分析工具能够对代码的规范，比如注释、命名、可能存在潜在缺陷的代码段、圈复杂度等进行分析。

静态分析工具的最大优势在于：

平台化支持，丰富的产品矩阵：比如既有面客的PC端平台，又有方面研发使用的IDE插件等等
校验的自动化执行能力：可以通过平台、IDE插件工具或是流水线（如果集成CICD）触发自动化执行并生成分析报告。

静态分析工具的不足主要表现在：

一般情况下，这些工具仅仅是提供建议的扫描报告，不具强流程控制，在约束打破时不会阻断应用构建。部分工具（并不是所有）与CICD流水线进行了打通，通过质量门禁来干预构建流程，一定程度上能作为系统约束校验的最后卡点。
静态分析工具的能力侧重点一般在于开发编码规范的约束，比如命名、注释、代码段规约等等，而对于高层的架构约束的校验较弱，比如分层架构约束、”组件“间约束、类位置约束、包与类的包含关系约束等等。
约束执行的粒度更倾向于统一规范，比如在团队维度、编程语言维度，而实际上忽略了应用级的定制化约束。不同的应用工程具备特定的应用架构风格，基于特定风格下有不同的架构约束。这些差异化规划与团队统一规则存在潜在冲突，并不一定在跨应用下都适用。