如何度量软件架构
1. 为什么要度量软件架构
不管是软件架构治理，还是研发效能治理，通过有效的指标度量都能协助找到问题并加以改进，指标也能反映改进后的效果。
指标很神奇，它就像是一个开关，如果你关注它，开关启动，可能会看到一些奇怪的反应。找到合适的指标让系统达到自己预期的效果，非常难。然而，这并不意味着我们要放弃通过指标度量的手段来解决问题。
通过指标来识别软件架构问题，就像医生依据检查报告上的指标诊断病人的病情一样。软件系统的运行可能远不及人体那么复杂，但随着系统规模的增大，系统的复杂度会远超一个人所能认知的范围，在这种情况下，很难通过架构师的经验来判断哪里有问题，像医生一样通过一些关键指标来找到问题无疑是更明智的选择。
医学发展到今天，病情诊断过程很多已经流程化，患者到医院说出疾病表现，医生就知道该做哪些检查，通过各种维度的“指标”数据来判断真实的病因。有些关键指标甚至能够直接帮助医生确诊疾病，比如针对新冠肺炎的核酸检测。
如果你无法度量它，你就无法管理它。—— 彼得·德鲁克
软件系统的维护者就像是医生，指标度量的重要性不言而喻，一方面可以通过度量找到系统架构的问题，另一方面也可以通过度量，来指导改进并观察改进效果。
2. 评价软件架构需要度量什么
Mamdouh Alenezi在论文《Software Architecture Quality Measurement Stability and Understandability》中整理了一些软件架构衡量标准和颗粒度定义，参见下表：
图片来源于论文《Software Architecture Quality Measurement Stability and Understandability》
图中给出的颗粒度包括包/类/方法，组件/库，架构三大类，我在之前的文章 《架构优化方向》[1] 中，将架构优化分为四个大的方向：代码实现、组件设计、架构设计和基础设施，在上面论文颗粒度的基础上增加的基础设施方向，目的是在静态代码和架构设计的基础上，增加对运行时状态的补充。
这四个维度涵盖了软件系统的顶层架构设计，到实际落地的代码质量，以及软件系统的运行时环境，从这四个维度入手进行优化，相信可以解决软件架构的大部分问题。
3. 通过哪些指标度量软件架构
然而，值得强调的是，给出一套度量标准用来衡量所有的软件架构是不切实际的。正如 ISO/IEC 25010 - Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models[2] 中提到：
It is not practically possible to specify or measure all subcharacteristics for all parts of a large computer system or software product. The relative importance of quality characteristics will depend on the high-level goals and objectives for the project.
这两句话放到10年后的今天依然成立，软件开发中没有银弹，不可能找到适合所有软件架构的度量方法和标准，从上文中《Software Architecture Quality Measurement Stability and Understandability》Table I 可见一斑，每篇论文给出的指标都不相同。在实际的软件架构设计和演进过程中，因业务场景不同，每个软件系统的架构关注点是不同的，设计目标也不同，自然对架构质量要求的重点就不同。
因此，在实际软件架构治理过程中，需要针对软件架构的特点，以及当前的问题，选择合适的度量指标来指导优化。下面就从代码实现，组件设计，架构设计和基础设施四个维度给出一些可以参考的指标，以及每个指标能够帮助识别哪些问题，进而通过这些指标找到提升软件架构健康度的方法。
代码实现相关指标
说到代码实现，大家一定会想到《Clean Code》以及《重构》，结合一些常用代码检查工具规则的定义，列举了一些常见的代码实现层面相关指标：
| 指标 | 计算方法 | 指标说明 |
| 圈复杂度 | 参考PMD: 圈复杂度 | 圈复杂度用来评估函数的复杂度，如果函数圈复杂度过高，表明函数有太多的决策变量，逻辑拆分不够，难以理解和维护 |
| 超大类占比 | 超大类数量/代码总量 | 超大类处理太多业务，职责不单一，业务耦合严重，不利于扩展和维护 |
| 超大函数占比 | 超大函数数量/代码总量 | 同上 |
| 重复代码频率 | 重复代码段发生次数 | 重复代码会让相同逻辑散落在不同的代码中，维护困难，容易产生修改过程中漏掉一部分导致问题 |
| 循环访问进程外组件频率 | 在循环中调用数据库或三方系统API的发生频率 | 循环访问进程外组件会引发性能问题 |
| 测试覆盖率 | 测试覆盖率 | 测试覆盖率不足，缺少对既有代码的保护，修改很难保证不影响之前的功能 |
组件设计相关指标
在组件自身设计上，也要遵循开发团队约定的设计原则，比如分层架构每层的职责，以及层与层之间的依赖关系。组件设计相关指标关注组件内部结构设计的合理性，以及一些交互机制的规范性，常用的指标如下：
| 指标 | 计算方法 | 指标说明 |
| 循环依赖[3]数量 | 类之间循环依赖次数 | 循环依赖打破了单向依赖原则，很难判断修改产生的影响。一旦出问题，非常难定位问题 |
| 类稳定性 | 参见Bob大叔《敏捷软件开发：原则、模式与实践》第20章 包的设计原则 | 稳定性是指改变的难易程度，对于希望类足够稳定的类，要控制依赖其他类的次数，提高被依赖的次数。稳定性应该顺着类依赖的方向递增 |
| 依赖异常数量 | 进程内模块分层依赖关系错误的次数 | 同循环依赖 |
| 组件间重复代码频率 | 公共功能代码重复发生次数 | 对于一些公共功能，没有抽象组件，复制粘贴代码，维护难度大 |
架构设计相关指标
架构设计相关指标关注组件之间的边界，交互关系的规范性，常见指标如下：
| 指标 | 计算方法 | 指标说明 |
| 组件循环依赖数量 | 组件之间循环依赖次数 | 组件间依赖关系混乱，职责不清 |
| 组件职责偏差率 | 组件职责与业务建模结果之间的偏差率 | 组件没有按业务合理划分，导致组件间关系复杂 |
| 组件稳定性 | 参见类稳定性 | 参见类稳定性说明 |
| 调用链长度 | 接口在多个组件间流转的次数 | 调用链越长，组件间依赖深度越大，依赖关系越复杂，排查问题越难 |
基础设施（运行时）相关指标
基础设施（运行时）相关指标从软件系统的运行时观测软件架构的健康度，从外在表现上找到系统的脆弱点，常见指标如下：
| 指标 | 计算方法 | 指标说明 |
| 基础设施负载率 | 基础设施资源，数据库，缓存的使用量 | 衡量当前系统是否到了瓶颈，能否应对突发的峰值请求 |
| 平均响应时间 | 生产环境API的平均响应时间 | 衡量软件架构的性能 |
| 系统可用性[4] | 系统在线可用的时间占比 | 衡量架构的稳定性和整体质量 |
| 平均故障恢复时长 | 故障发生后恢复可用的平均时长 | 衡量架构在应对突发问题时快速恢复的能力 |
| 数据不一致[5]问题占比 | 数据不一致问题占所有问题的比例 | 数据不一致通常是因为架构设计不合理，或组件交互方式不合理导致的 |
| 无用功能占比 | 生产环境长期不使用功能的占比 | API或者某些功能长期不使用需要尽快清理，降低认知负载，也有助于优化组件之间的关系 |
4. 度量之外
指标度量对于软件架构治理很重要，就像文章开头的隐喻，医生要看到各种检查指标的结果才能给出诊断，没有这些指标，大部分医生是没法坐诊的。然而，医生出具诊断时，指标只是作为参考，医生的专业知识和经验在诊断过程中起到至关重要的作用，也有常见的情况是指标异常，但医生仍然会说，不是什么大问题，定期复查，多运动，注意饮食。
除了可度量的指标，实际软件架构治理的过程中，也会有很多不可度量且非常重要的指标。就像行军打仗，能打硬仗的队伍不一定所有的指标都好看，但不妨碍它的战绩。因此，指标度量的要点是帮助开发团队更好地理解系统，理解架构，找到问题，设计解决方案，不断优化以达到软件架构治理的目标，切不可为了指标而度量。
References
[1] 《架构优化方向》: https://www.maguangguang.xyz/architecture-optimization-topics[2] ISO/IEC 25010 - Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models: https://www.iso.org/standard/35733.html[3] 循环依赖: https://www.maguangguang.xyz/eliminate-cyclic-dependency[4] 系统可用性: https://www.maguangguang.xyz/how-to-improve-system-availability[5] 数据不一致: https://www.maguangguang.xyz/data-consistency