在敏捷开发环境下，系统通过迭代增量的交付价值，系统架构也是如此。团队不可能在项目之初就建立完美的系统架构，系统架构应该随着系统迭代不断演进。架构演进和架构腐化是看待架构的不同视角：架构腐化着眼于现状，架构演进侧重于未来架构腐化不可避免，随着时间流转腐化现象必然发生。而我们需要做的是：通过某种方式及早发现和修正
把目光从宏观的演进和腐化视角聚焦在更加具体的问题和挑战层面，作为团队负责人或架构师，你是否面临以下问题：
•团队已经制定的开发规范很难持续性的落地，并在应用中保持较高的健康状态
•系统制定的架构决策在系统迭代过程中逐渐弱化、打破，甚至随着时间的推移，团队中已经没有人关注决策的落地和遵守情况
•历史的架构决策早已 ” 无迹可寻 “，更何谈对系统架构演进的追溯
•如何快速的判断当前系统腐化程度或健康情况？
•不论是架构升级、系统演进，系统缺失指导性的自动化约束，确保演进方向不会偏离
基于以上的问题，我相信团队都会做过一些实践，不管是流程的强约束，还是系统的自动化，都尝试解决如上所面临的所有或部分问题。典型的方式：
•方式一：代码评审 (强流程)
•方式二：静态分析工具，并结合 CICD 流水线
•方式三：基于 ArchUnit 的架构约束单元测试实践
代码评审是最典型的方式，对每次迭代的代码交付进行强流程的评审，通过多干系人参与，可以灵活的、深入的评估实现对于约束的遵守情况。当然，评审越完备，需评审人员投入的精力和时间成本越大。
大量的开发实践表明，系统无法持续保持高强度的、完备的代码评审，评审的力度会由于各种因素而下降，最终导致系统的腐化，这种人为不可控因素是代码评审的主要问题。
另外一个问题是，代码评审在研发流程中的后置性。一般情况下，代码评审介入的实际可能是在开发提测之后，联调结束之前，当然有些团队可能更后置。流程越后置，如果存在大规模的架构约束破坏，则可能导致重构成本与项目周期的冲突。
代码的静态分析工具比较多，比如 CheckStyle 、FindBug、Sonar，公司内部的 EOS 等等，这些静态分析工具能够对代码的规范，比如注释、命名、可能存在潜在缺陷的代码段、圈复杂度等进行分析。
静态分析工具的最大优势在于：
•平台化支持，丰富的产品矩阵：比如既有面客的 PC 端平台，又有方面研发使用的 IDE 插件等等
•校验的自动化执行能力：可以通过平台、IDE 插件工具或是流水线（如果集成 CICD）触发自动化执行并生成分析报告。
静态分析工具的不足主要表现在：
•一般情况下，这些工具仅仅是提供建议的扫描报告，不具强流程控制，在约束打破时不会阻断应用构建。部分工具（并不是所有）与 CICD 流水线进行了打通，通过质量门禁来干预构建流程，一定程度上能作为系统约束校验的最后卡点。
•静态分析工具的能力侧重点一般在于开发编码规范的约束，比如命名、注释、代码段规约等等，而对于高层的架构约束的校验较弱，比如分层架构约束、” 组件 “间约束、类位置约束、包与类的包含关系约束等等。
•约束执行的粒度更倾向于统一规范，比如在团队维度、编程语言维度，而实际上忽略了应用级的定制化约束。不同的应用工程具备特定的应用架构风格，基于特定风格下有不同的架构约束。这些差异化规划与团队统一规则存在潜在冲突，并不一定在跨应用下都适用。
ArchUnit 是一个基于 Junit 运行的架构约束类库，其能够通过单元测试的形式对系统架构约束进行自动化的校验。团队引入 ArchUnit 的成本并不高，由于是基于单元测试形式引入，并不影响应用程序的主线流程。团队在引入往往有集中形式：
•单个应用引入，每个应用都定义各自的单测
•公共 jar 包，多应用复用
上述应用模式也同样在统一规范和应用差异化层面存在类似的问题。
以上的三种实践方案存在以下几个共性问题无法解决：
•团队统一规范和应用级别的定制化支持
•架构决策记录的管控与追踪
•多维度的架构指标分析
基于对已有问题及解决方案的分析，我们希望平台化的解决方案，ArchKeeper 平台建设的核心目标如下：
•架构约束自动化测试能力：支持架构约束的自动化执行
•灵活、简单的规则扩展能力：规则的定制扩展应尽量保持简单、灵活，满足实际的定制化需求
•团队统一规范与应用扩展规则的统一执行
•结果及时反馈，支持与 CICD 流水线集成：自动化执行前置到开发阶段，并通过 CICD 流水线作为最后卡点
•ADR 管控与追踪：以产品线和应用为载体，对系统的架构决策进行统一管控，并具备 ADR 的可视化追溯能力
•架构约束静态分析模式，以评估架构腐化：基于代码仓库及规则库的静态分析能力，以提供高层的应用规则分析报表
•多维度架构治理指标分析能力：对应用提供更多维度的指标分析，比如组件耦合度等，为架构演进提供指引
理念一：架构约束是强制规则，应用必须遵守，否则应阻断应用构建
系统的架构决策是影响系统的 “重要” 的东西，决策评审通过之后应确保应用的遵循，团队应该评估校验决策执行的方式，比如哪些可以自动化校验，哪些需要基于人工审查。对于支持自动化校验的架构约束，应用必须遵守，不能破坏约束限制。因此，如果存在破坏约束情况，应当阻断应用构建。
理念二：架构约束测试的执行应该尽量前置，及时反馈
流程后置带来的问题就是如果存在架构约束的破坏，研发进行重构需要一定时间成本。流程越后置，重构成本越高。因此，架构约束的自动化执行应该尽量前置，提前至开发阶段，并尽可能的及时反馈校验结果以提升效率。
理念三：架构约束无法完全统一，在团队统一规范之外，允许应用级的定制，且须统一执行
架构约束的范围比较广，团队无法形成完全统一的、标准一致的约束规范。有些约束是团队层面的，比如编码规范中的某些强制约束。而有些则是应用级别的，比如特定应用下的分层约束等等。因此，这种定制化是必然存在的。虽然，团队统一约束和应用级别的定制化约束无法完全统一，但二者应该在统一的自动化流程中执行。
理念四：系统的架构决策记录应当留存并可追溯
系统的架构决策记录（ADR）是团队的重要资产，ADR 应该以文档化形式留存，并能够对 ADR 的演进提供追溯能力。
理念五：多维度的架构指标分析有利于防止架构腐化，为架构演进提供指引
ArchKeeper 平台之所以计划提供多维度架构指标的分析能力正是基于这样一个前提理念：对应用进行多维度的架构指标分析，有利于观测系统的腐化情况，并为系统的架构演进提供一定的指引。
文章主要阐述了研发中存在的问题及 ArchKeeper 平台化建设理念及目标，并没有涉及具体的实现。后续的系列文章会对 ArchKeeper 能力规划、设计实现 (基于 DDD) 进行持续的分享交流。
