作者：京东科技 倪新明
在麻利开发环境下，零碎通过迭代增量的交付价值，零碎架构也是如此。团队不可能在我的项目之初就建设完满的零碎架构，零碎架构应该随着零碎迭代一直演进。架构演进和架构腐化是对待架构的不同视角：架构腐化着眼于现状，架构演进侧重于将来架构腐化不可避免，随着工夫流转腐化景象必然产生。而咱们须要做的是：通过某种形式及早发现和修改
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) 进行继续的分享交换。
关联文章：
《通过自动化单元测试的模式守护零碎架构》
《轻量级的架构决策记录机制》