共计 2182 个字符，预计需要花费 6 分钟才能阅读完成。
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 进行架构束缚自动化查看后，将对以下方面产生影响：
- 有助于升高零碎架构腐化，晋升零碎可维护性
- 新类库引入有肯定的学习老本
- 代码评审流动减少一项流动：执行架构束缚单元测试
- 开发成员日常开发中须要继续执行并关注架构束缚单测后果，并确保测试通过