Day944.度量指标 -系统重构实战

度量指标

Hi，我是阿昌，今天学习记录的是关于度量指标的内容。

很多时候在研发过程中，都习惯性地用“拍脑袋”的方式来看待一个事情。例如这个代码写得不好、这个自动化测试覆盖不充分、版本的发布频率太差了等等。往往只知道哪里有问题，但是却不知如何去找出根因，真正改进。对于这种情况就需要我们引入度量。

通过 度量指标，可以让在研发过程中更加明确目标，避免一开始就走成了反方向，另外，完成了阶段性工作后，又可以通过持续的度量来反馈完成的情况，帮助我们持续地改进。软件开发中，从需求到上线运营的每个阶段都有大量的度量指标，之前自动化测试就从生命周期的视角提供了不少指标。

---

一、开发指标

首先来看看开发相关的度量指标。通常问题比较多的度量指标，分别为圈复杂度、代码重复率、无效代码行以及代码耦合度。

其中圈复杂度、代码重复率、无效代码在五类遗留系统典型的代码坏味道中就讲过了，这重点介绍指标的目的以及如何在实践中运用这些指标。

1、圈复杂度

圈复杂度 指的是代码的嵌套复杂度。这个指标的度量目的很明显，如果圈复杂度高，就意味着代码的嵌套复杂度过高，不利于阅读理解以及测试。

很多遗留系统的问题就是缺少重构，导致大量庞大的类及方法，后续不管是扩展功能或者修改逻辑都非常容易出问题。

在实践过程中，一般结合流水线，在质量门禁中的静态代码扫描环节进行检查。

一般来说圈复杂度不能超过 10，而且越小越好。

当提交的代码不符合要求时，则限制代码合入。

---

2、代码重复率

重复代码 指的是代码中有两个地方以上存在相同的代码行。这个指标的作用也非常明显。如果存在大量的重复代码，特别是 2 个相同的类只有个别的代码行差异，当相同部分的逻辑有变化的时候，就会导致需要在多个地方修改代码，这就是所谓的“散弹式修改”。

在实践过程中，同样可以结合流水线，在质量门禁中检查代码重复率，一般建议不超过 5%。当提交的代码不符合要求时，同样要限制代码的合入。

---

3、无效代码行

无效代码 指的是没有被调用的类、方法或者资源等内容。虽然无效代码不会影响功能，但是会影响整体阅读代码的体验，尤其是理解代码的难易程度。在遗留系统中，无效代码也是非常常见的问题。

同样可以结合流水线进行静态代码检查，如果发现有无效的代码行则反馈给相关人员，要求其修改。在日常的开发过程中，也应该关注 IDE 的提示，在提交前保证代码的整洁。

---

4、代码耦合度

那么什么样才算耦合呢？这里的 耦合 指的是所有不符合架构规则的代码调用关系就算耦合。

具体可以参考运用自动化工具诊断分析Sharing项目中对 Sharing 项目的耦合分析。

当然这里有一个前提，一定是得有架构设计以及架构规则，因为如果没有规则，就没有耦合的判断依据。如果代码存在前面说的耦合情况，就代表目前的代码不符合架构的设计规则，日积月累，架构就会不断地腐化。

在在实践中，需要将架构守护变成自动化测试用例，加入到流水线的质量门禁中，以便在代码提交存在耦合时，能够及时发现并反馈。

---

二、自动化测试指标

自动化测试 是需要投入设计及维护，如果编写的自动化测试用例没有被执行，那么相当于就是白费力气。所以针对自动化测试进行持续度量是一项非常重要的工作。

下面，来看看自动化测试度量相关的 4 个常用关键指标，分别为测试用例数、执行频率、执行时长以及执行成功率。

1、测试用例数

测试用例数 指的是持续执行的自动化测试用例的总数。

可以通过观察这个指标来看项目整体自动测试投入的变化。

正常情况下，有效的自动化测试用例随着业务的迭代，测试的数量应该持续地增加，如果测试的数量存在大幅波动，应该重点做分析。

可以通过测试报告来获取测试的用例数，然后结合持续集成工具来统计用例数的变化。

---

2、执行频率

自动化测试执行频率 指的是自动化测试每天执行的次数。

无论是自动化测试的设计还是维护，都需要成本，所以只有频繁的执行才能发挥其价值。

通常自动化测试都会接入到持续集成流水线中。所以，可以通过观察自动化测试的执行频率，来查看自动化测试是否充分地执行了。

---

3、执行时长

自动化测试执行时长 指的是一套自动化测试用例执行所需的时间。

自动化测试的一个重要目标是验证反馈，所以反馈的周期越短，那么作用就更大。所以应该持续观察自动化测试用例执行的时长，这个数据也可以通过测试用例报告获得。

在实践过程中，如果发现有个别用例的执行时间非常长，应该重新检查。通常来说，小型测试的执行时间是毫秒级别，中大型测试的执行时间是秒级别。

---

4、执行成功率

自动化测试执行成功率 指的是自动化测试执行后通过的测试用例数除以测试用例总数。

如果存在用例执行失败的情况，应该及时分析，排除引入或破坏业务逻辑问题。实践当中，要避免为了让代码可以合入而注释掉失败用例的情况。另外，自动化测试执行成功率也能从某种程度反应开发代码提交的质量，建议持续观察这个指标。

---

三、流水线指标

当团队使用了流水线来集成发布软件时，流水线的执行情况直接反映了团队的效率以及版本的质量。所以在实践过程中，一定要持续关注流水线运行的相关指标。

流水线中常用的 4 个关键指标，分别为构建频率、构建时长、构建成功率以及平均恢复时长。

关于这 4 个指标，通常的持续集成工具都有插件支持统计查询。

1、构建频率

构建频率 指的是一段时间内持续集成流水线执行的平均频率。

如果主干日均执行频率低于 1 次，那么证明团队的代码合入频率非常低。出现这种情况，就需要去排查是任务的拆分粒度过大，还是开发人员没有及时集成代码。至少需要保证主干每天都能成功构建出一个最新可用的版本。

---

2、构建时长

构建时长 指的是一段时间内持续集成流水线执行的平均时长。这个指标关乎着开发人员代码合入的效率。在实际的团队辅导过程中，我曾遇到持续集成流水线平均执行时长接近 2 个小时，这反过来会影响开发人员代码合入的意愿，变成另外一个瓶颈。

针对流水线执行时间过长的的问题，需要先排查具体耗时的步骤，再针对性解决。另外，也可以采用并发以及分级的形式来提高效率。

---

3、构建成功率

构建成功率 指的是一段时间内持续集成流水线成功执行的次数除以执行的总数所得的比率。

如果在一段时间内执行成功率非常低，例如低于 60%，在排查掉一些环境的影响因素后，则证明这段时间内代码提交的质量不高，则需要具体分析执行失败的任务，并及时调整。

---

4、平均恢复时长

平均恢复时长 指的是一段时间内持续集成流水线从失败转变为成功的平均间隔时间。

通过这个指标可以促进团队更加关注流水线的运行情况。因为可以根据这个指标，判断开发人员对持续集成纪律的遵守情况，比如，是否能在流水线执行失败后立马修复。

---

四、总结

通过 度量指标 可以帮助明确方向，及时反馈结果，推动持续改进。

通常在项目中，都会搭建度量相关的看板来持续观察数据的变化，同时也会在团队定期的回顾会上，复盘这些数据制定改进目标。

不建议团队将度量指标纳入 KPI 中，这样非常容易导致走向另外一个极端，失去了度量关键的意义。

下面度量指标的定义、目的、建议阈值及趋势等总结成表格。给出了一些通用的建议参考阈值，具体的产品不同，情况可能会有差异。

---