如何度量软件架构丨IDCF

来源：码猿外

作者：麻广广

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 可见一斑，每篇论文给出的指标都不相同。在实际的软件架构设计和演进过程中，因业务场景不同，每个软件系统的架构关注点是不同的，设计目标也不同，自然对架构质量要求的重点就不同。

因此，在实际软件架构治理过程中，需要针对软件架构的特点，以及当前的问题，选择合适的度量指标来指导优化。下面就从代码实现，组件设计，架构设计和基础设施四个维度给出一些可以参考的指标，以及每个指标能够帮助识别哪些问题，进而通过这些指标找到提升软件架构健康度的方法。

3.1代码实现相关指标

说到代码实现，大家一定会想到《Clean Code》以及《重构》，结合一些常用代码检查工具规则的定义，列举了一些常见的代码实现层面相关指标：

指标	计算方法	指标说明
圈复杂度	参考PMD: 圈复杂度	圈复杂度用来评估函数的复杂度，如果函数圈复杂度过高，表明函数有太多的决策变量，逻辑拆分不够，难以理解和维护
超大类占比	超大类数量/代码总量	超大类处理太多业务，职责不单一，业务耦合严重，不利于扩展和维护
超大函数占比	超大函数数量/代码总量	同上
重复代码频率	重复代码段发生次数	重复代码会让相同逻辑散落在不同的代码中，维护困难，容易产生修改过程中漏掉一部分导致问题
循环访问进程外组件频率	在循环中调用数据库或三方系统API的发生频率	循环访问进程外组件会引发性能问题
测试覆盖率	测试覆盖率	测试覆盖率不足，缺少对既有代码的保护，修改很难保证不影响之前的功能

3.2组件设计相关指标

在组件自身设计上，也要遵循开发团队约定的设计原则，比如分层架构每层的职责，以及层与层之间的依赖关系。组件设计相关指标关注组件内部结构设计的合理性，以及一些交互机制的规范性，常用的指标如下：

指标	计算方法	指标说明
循环依赖[3]数量	类之间循环依赖次数	循环依赖打破了单向依赖原则，很难判断修改产生的影响。一旦出问题，非常难定位问题
类稳定性	参见Bob大叔《敏捷软件开发：原则、模式与实践》第20章 包的设计原则	稳定性是指改变的难易程度，对于希望类足够稳定的类，要控制依赖其他类的次数，提高被依赖的次数。稳定性应该顺着类依赖的方向递增
依赖异常数量	进程内模块分层依赖关系错误的次数	同循环依赖
组件间重复代码频率	公共功能代码重复发生次数	对于一些公共功能，没有抽象组件，复制粘贴代码，维护难度大

3.3架构设计相关指标

架构设计相关指标关注组件之间的边界，交互关系的规范性，常见指标如下：

指标	计算方法	指标说明
组件循环依赖数量	组件之间循环依赖次数	组件间依赖关系混乱，职责不清
组件职责偏差率	组件职责与业务建模结果之间的偏差率	组件没有按业务合理划分，导致组件间关系复杂
组件稳定性	参见类稳定性	参见类稳定性说明
调用链长度	接口在多个组件间流转的次数	调用链越长，组件间依赖深度越大，依赖关系越复杂，排查问题越难

3.4基础设施（运行时）相关指标

基础设施（运行时）相关指标从软件系统的运行时观测软件架构的健康度，从外在表现上找到系统的脆弱点，常见指标如下：

指标	计算方法	指标说明
基础设施负载率	基础设施资源，数据库，缓存的使用量	衡量当前系统是否到了瓶颈，能否应对突发的峰值请求
平均响应时间	生产环境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

#IDCF DevOps黑客马拉松挑战赛，独创端到端DevOps体验，精益创业+敏捷开发+DevOps流水线的完美结合。

2022年首场将在美丽的海滨城市-大连举办，8月6-7日，36小时内从0到1打造并发布一款产品。

企业组队参赛&个人参赛均可，赶紧上车~👇