软件架构度量

当今软件的规模在急剧增大，对于软件开发来说，能否做到架构及时监测与重构，是一件事关业务兴衰的头等大事，不管是软件架构治理，还是研发效能治理，都需要通过有效的指标度量协助研发人员快速找到系统问题并加以改进，下面是一些常用的软件度量指标，如下：

1、代码实现指标

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

2、组件设计指标

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

3、架构设计指标

指标	计算方法	指标说明
组件循环依赖数量	组件之间循环依赖次数	组件间依赖关系混乱，职责不清
组件职责偏差率	组件职责与业务建模结果之间的偏差率	组件没有按业务合理划分，导致组件间关系复杂
组件稳定性	参见类稳定性	参见类稳定性说明
调用链长度	接口在多个组件间流转的次数	调用链越长，组件间依赖深度越大，依赖关系越复杂，排查问题越难
负载率	基础设施资源，数据库，缓存的使用量	衡量当前系统是否到了瓶颈，能否应对突发的峰值请求
平均响应时间	生产环境API的平均响应时间	衡量软件架构的性能
系统可用性	系统在线可用的时间占比	衡量架构的稳定性和整体质量
平均故障恢复时长	故障发生后恢复可用的平均时长	衡量架构在应对突发问题时快速恢复的能力
数据不一致问题占比	数据不一致问题占所有问题的比例	数据不一致通常是因为架构设计不合理，或组件交互方式不合理导致的
无用功能占比	生产环境长期不使用功能的占比	API或者某些功能长期不使用需要尽快清理，降低认知负载，也有助于优化组件之间的关系