如何确定代码审查过程的有效性？

我们已经在组织内部引入了代码审查流程，并且看起来运行良好。但是，我希望能够随着时间的推移来衡量该过程的有效性，即我们是不是因为代码干净而没有发现bug，还是人们只是没有发现bug？

当前，我们没有有效的全自动测试过程。我们主要采用手动测试，因此我们不能依靠现阶段发现的缺陷来确保代码审查过程正常进行。

是否有人之前曾遇到过此问题，或对衡量代码审查的效果如何有任何想法？

可以从代码审查中收集许多指标，有些甚至可以扩展到项目的整个生命周期。

我建议收集的第一个指标是缺陷去除效率（DRE）。对于每个缺陷，您都可以确定引入缺陷的阶段以及消除缺陷的阶段。同时使用的各种缺陷检测技术都将同时进行评估，因此它同样适用于需求评审，设计评审，代码评审和单元测试。 ， 等等。您可能会对代码阶段捕获的缺陷数量特别感兴趣，因为这可能包含您的单元测试和代码检查。如果从代码阶段到集成测试阶段甚至整个领域都存在许多缺陷，那么您就应该对后期编码实践进行评估。

各种会议指标也将是相关的。这些包括准备时间，开会时间，代码行读取，审查中发现的缺陷等等。从这些数据可以得出一些观察结果。例如，如果您的审阅者花大量时间阅读代码以准备进行审阅，但发现的问题很少。结合DRE数据，您可以得出以下结论：如果缺陷是在集成测试或现场中进行测试，则您的团队需要专注于其检查技术以发现问题。另一个有趣的注释是与会议时间相比，在会议中读取的代码行（或其他尺寸度量）。研究发现，典型的代码审查速度为每小时150行代码。

使用这些指标中的任何一个，那么重要的是要了解它们对流程的影响。可以使用诸如why-because，Five Whys或Ishikawa图之类的技术进行根本原因分析，以确定代码审查（或任何其他质量改进技术）无效的原因。

您可能也有兴趣在这篇文章中有关从Ganssle集团视察，并通过卡珀斯·琼斯在相声有关缺陷潜力和DRE的文章。

尽管在很大程度上代码审查确实可以发现问题，但这些问题很可能会导致测试无法发现。但是，我认为您可能有一个非常稳定的代码（实际上没有错误），但是仍然以极其不可读或不太可维护的方式编写。因此，它可能是代码审查可能不发现错误，如果有在代码实际上没有真正的问题。

话虽如此，我真的会问，为什么要进行代码审查？这样做很重要的简单原因是，应该对代码进行改进，使其更具可读性，可维护性和可发展性。许多人应该能够阅读更清晰的代码并从中受益。从这个意义上讲，代码审查过程的最简单目标是生成干净的代码。因此，有效性的衡量标准是现在的代码有多干净。

正如您想获得可衡量的效果-这是我的建议：

1. 公制涉及到返工量-的返工是在同一个给定的模块/对象/工作项目申请时间数量是如何衡量贫穷的代码是在可维护性方面。当应用有效的代码审阅时，我们能够多久减少同一模块上的返工请求？

2. 与每个变更请求所引起的变更量相关的指标。每次发生更改请求时- 分解不良的代码将始终会影响大量模块。一项措施可能表明，在对代码进行审查之后- 过去对于类似变更请求的这种变更分布是否有所减少？

3. 与可以响应更改请求的平均速度有关的指标。当代码更清晰时-越来越好，它是对所需更改的响应。在检查过程中清除代码后，我们发现在响应相似大小的请求时，速度有所提高。

我没有给出确切的度量单位-您可能可以通过这种方法针对此制定更精确的度量。在上述方法上，可以有更多的扩展形式主义。

基本上，我的观点是，与其着眼于代码审查过程所确定的错误数量，不如说是数量。我们应该根据代码审查是否能够使代码更整洁，更精简和易于维护的状态来衡量有效性；因此，如果我们看到将来类似的变更请求变得更加有效，可以衡量该有效性。