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 中，如许非常容易导致走向别的一个极端，失去了度量关键的意义。
下面度量指标的定义、目标、发起阈值及趋势等总结成表格。给出了一些通用的发起参考阈值，具体的产物不同，情况可能会有差异。

---

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。