你好，我是黄俊彬。
很多时候在研发过程中，我们都习惯性地用“拍脑袋”的方式来看待一个事情。例如这个代码写得不好、这个自动化测试覆盖不充分、版本的发布频率太差了等等。往往只知道哪里有问题，但是却不知如何去找出根因，真正改进。
对于这种情况就需要我们引入度量。通过度量，可以让我们在研发过程中更加明确目标，避免一开始就走成了反方向，另外，完成了阶段性工作后，又可以通过持续的度量来反馈完成的情况，帮助我们持续地改进。
软件开发中，从需求到上线运营的每个阶段都有大量的度量指标，之前第2节课就从生命周期的视角提供了不少指标。而今天我要和你探讨的指标，和开发更加息息相关。
我会专门带你了解研发过程中开发、测试、构建发布这3个过程都有哪些关键的度量指标，这些指标背后的用意以及我们在实践中如何合理运用这些指标。
开发指标
首先我们来看看开发相关的度量指标。这里我挑选了4个遗留系统中通常问题比较多的度量指标，分别为圈复杂度、代码重复率、无效代码行以及代码耦合度。
其中圈复杂度、代码重复率、无效代码我们在第8节课中就讲过了，这里我们重点介绍指标的目的以及如何在实践中运用这些指标。
1.圈复杂度
首先来看看圈复杂度。圈复杂度指的是我们代码的嵌套复杂度。
这个指标的度量目的很明显，如果圈复杂度高，就意味着代码的嵌套复杂度过高，不利于阅读理解以及测试。
很多遗留系统的问题就是缺少重构，导致大量庞大的类及方法，后续不管是扩展功能或者修改逻辑都非常容易出问题。在实践过程中，我们一般结合流水线，在质量门禁中的静态代码扫描环节进行检查。一般来说圈复杂度不能超过10，而且越小越好。当提交的代码不符合要求时，则限制代码合入。
2.代码重复率
第二个指标是代码重复率。重复代码指的是代码中有两个地方以上存在相同的代码行。
这个指标的作用也非常明显。如果存在大量的重复代码，特别是2个相同的类只有个别的代码行差异，当相同部分的逻辑有变化的时候，就会导致我们需要在多个地方修改代码，这就是所谓的“散弹式修改”。
在实践过程中，我们同样可以结合流水线，在质量门禁中检查代码重复率，一般建议不超过5%。当提交的代码不符合要求时，同样要限制代码的合入。
3.无效代码行
第三个指标是无效代码行。无效代码指的是没有被调用的类、方法或者资源等内容。
虽然无效代码不会影响功能，但是会影响整体阅读代码的体验，尤其是理解代码的难易程度。在遗留系统中，无效代码也是非常常见的问题。我们同样可以结合流水线进行静态代码检查，如果发现有无效的代码行则反馈给相关人员，要求其修改。在日常的开发过程中，我们也应该关注IDE的提示，在提交前保证代码的整洁。
4.代码耦合度
第四个指标是代码耦合度。那么什么样才算耦合呢？这里的耦合指的是所有不符合架构规则的代码调用关系就算耦合。具体你可以参考第7节课中我们对Sharing项目的耦合分析。
当然这里有一个前提，一定是我们得有架构设计以及架构规则，因为如果没有规则，我们就没有耦合的判断依据。
如果代码存在前面说的耦合情况，就代表目前的代码不符合架构的设计规则，日积月累，架构就会不断地腐化。在在实践中，我们需要将架构守护变成自动化测试用例，加入到流水线的质量门禁中，以便在代码提交存在耦合时，能够及时发现并反馈。
自动化测试指标
我们都知道自动化测试是需要投入设计及维护，如果编写的自动化测试用例没有被执行，那么相当于就是白费力气。所以针对自动化测试进行持续度量是一项非常重要的工作。
下面，我们来看看自动化测试度量相关的4个常用关键指标，分别为测试用例数、执行频率、执行时长以及执行成功率。
1.测试用例数
首先来看测试用例数。测试用例数指的是持续执行的自动化测试用例的总数。
我们可以通过观察这个指标来看项目整体自动测试投入的变化。正常情况下，有效的自动化测试用例随着业务的迭代，测试的数量应该持续地增加，如果测试的数量存在大幅波动，应该重点做分析。我们可以通过测试报告来获取测试的用例数，然后结合持续集成工具来统计用例数的变化。
2.执行频率
第二个指标是执行频率。自动化测试执行频率指的是自动化测试每天执行的次数。
无论是自动化测试的设计还是维护，都需要成本，所以只有频繁的执行才能发挥其价值。通常自动化测试都会接入到持续集成流水线中。所以，我们可以通过观察自动化测试的执行频率，来查看自动化测试是否充分地执行了。
3.执行时长
第三个指标是执行时长。自动化测试执行时长指的是一套自动化测试用例执行所需的时间。
自动化测试的一个重要目标是验证反馈，所以反馈的周期越短，那么作用就更大。所以我们应该持续观察自动化测试用例执行的时长，这个数据我们也可以通过测试用例报告获得。
我想提示你注意，在实践过程中，如果发现有个别用例的执行时间非常长，我们应该重新检查。通常来说，小型测试的执行时间是毫秒级别，中大型测试的执行时间是秒级别。
4.执行成功率
最后一个指标是执行成功率。自动化测试执行成功率指的是自动化测试执行后通过的测试用例数除以测试用例总数。**
如果存在用例执行失败的情况，应该及时分析，排除引入或破坏业务逻辑问题。实践当中，要避免为了让代码可以合入而注释掉失败用例的情况。另外，自动化测试执行成功率也能从某种程度反应开发代码提交的质量，建议持续观察这个指标。
流水线指标
当团队使用了流水线来集成发布软件时，流水线的执行情况直接反映了团队的效率以及版本的质量。所以在实践过程中，我们一定要持续关注流水线运行的相关指标。
接下来，我带你了解一下流水线中常用的4个关键指标，分别为构建频率、构建时长、构建成功率以及平均恢复时长。关于这4个指标，通常的持续集成工具都有插件支持统计查询。
1.构建频率
构建频率指的是一段时间内持续集成流水线执行的平均频率。
如果主干日均执行频率低于1次，那么证明团队的代码合入频率非常低。出现这种情况，就需要去排查是任务的拆分粒度过大，还是开发人员没有及时集成代码。我们至少需要保证主干每天都能成功构建出一个最新可用的版本。
2.构建时长
构建时长指的是一段时间内持续集成流水线执行的平均时长。这个指标关乎着开发人员代码合入的效率。
在实际的团队辅导过程中，我曾遇到持续集成流水线平均执行时长接近2个小时，这反过来会影响开发人员代码合入的意愿，变成另外一个瓶颈。
针对流水线执行时间过长的的问题，我们需要先排查具体耗时的步骤，再针对性解决。另外，也可以采用并发以及分级的形式来提高效率。
3.构建成功率
构建成功率指的是一段时间内持续集成流水线成功执行的次数除以执行的总数所得的比率。
如果在一段时间内执行成功率非常低，例如低于60%，在排查掉一些环境的影响因素后，则证明这段时间内代码提交的质量不高，则需要具体分析执行失败的任务，并及时调整。
4.平均恢复时长
平均恢复时长指的是一段时间内持续集成流水线从失败转变为成功的平均间隔时间。
通过这个指标可以促进团队更加关注流水线的运行情况。因为我们可以根据这个指标，判断开发人员对持续集成纪律的遵守情况，比如，是否能在流水线执行失败后立马修复。
总结
今天我给你分享了研发过程中关于代码、测试以及流水线相关的度量指标。
通过度量可以帮助我们明确方向，及时反馈结果，推动持续改进。通常在项目中，我们都会搭建度量相关的看板来持续观察数据的变化，同时也会在团队定期的回顾会上，复盘这些数据制定改进目标。
不过，我并不建议团队将度量指标纳入KPI中，这样非常容易导致走向另外一个极端，失去了度量关键的意义。
下面我将这些度量指标的定义、目的、建议阈值及趋势等总结成表格，供你参考。我给出了一些通用的建议参考阈值，具体的产品不同，情况可能会有差异。
至此，我们完成了持续交付篇的学习，正如开篇所说，针对代码的重构只是解决遗留系统问题的一个关键举措，如果想根治遗留系统，就得从软件工程的角度来看待它。
所以在日常的开发过程中，我们必须要重视项目的分支、版本管理、构建、测试、流水线等实践，才能更好帮助我们高效、高质量交付软件。
下节课开始将进入扩展篇，我们将从应用的解耦视角上升到对个定制Android系统解耦，敬请期待。
思考题
感谢你学完了今天的内容，今天的思考题是这样的：你的项目上正在使用哪些度量指标呢？你们是如何运用这些指标来持续改进？
文章来源：极客时间《大型 Android 系统重构实战》