为什么diff审查的速度总是那么慢？

代码审查是软件开发过程中最重要的环节之一。如果这项工作做得好，代码审查能够切实帮助我们发现 bug，普及最佳实践并保障代码质量。

近日，Meta 技术团队宣布采用了几款工具和相应流程，很大程度提高了代码审查速率。

Meta 技术团队将针对代码库做出的一组独立变更称为“diff”。虽然 Meta 非常重视开发效率，但每条 diff 也必须经受严格审查，绝无例外。代码审查团队深知审查周期越长，留给开发者们完成工作的时间就会越短。

为此，Meta 技术团队研究了多项指标，希望更多了解哪些代码审查瓶颈最令开发者们感到不满，并积极利用这些结论探寻在不牺牲审查质量的前提下加快审查速度的办法。通过研究发现，缓慢的 diff 审查速度跟工程师们的不满情绪间存在相关性。另外，新研发的工具能够在审查周期的各个关键节点向相应审查人员展示 diff，由此显著改善审查体验。

为什么 diff 审查的速度总是那么慢？

为了回答这个问题，首先需要查看自己的数据。在跟踪了一项名为“审查时间”的指标后，Meta 技术团队发现，需要衡量的是 diff 在单一审查周期内等待审查的时长。这里只计算 diff 等待审查者操作的时间。

审查时间（Time In Review）指标，计算的就是图中各蓝色部分（即无意义等待部分）耗费的时间总和。

最终的发现令人惊讶。回顾 2021 年初的数据，研发人员发现 diff 审查时间的中位数（第 50 百分位）只有几个小时，这样的结果还算不错。但如果把目光投向第 75 百分位（即最慢的那四分之一审查），就会发现diff 的审查时间延长到了一整天。

研发人员分析了审查时间跟用户满意度（通过全公司范围内的量化调查）之间的相关性。结果非常明确：速度最慢的那 25% diff 审查，才是决定人们实际体验的核心；这部分耗时越长，大家对代码审查过程的满意度就越低。于是也就得出了最值得关注的改进指标：第 75 百分位（P75）审查时间。

缩短审查时间不单能让人们对整个代码审查过程的满意度更高，也会提高每一位 Meta 工程师的工作效率。缩短 diff 审查时间，意味着工程师耗费在审查上的时间将大大减少、提升工作效率、改善审查体验。

在速度与质量间求取平衡

然而，简单粗暴地加快审查速度绝不是明智之举，甚至会将审查变成毫无意义的走过场。因此需要设置一项护栏指标，防止过快审查带来的负面后果。在这里，研究人员选择了“注视时间”，即审查者花在查看 diff 上的总时长。查看时间过短，即代表审查者很可能是在敷衍了事。

现在已经有了核心指标“审查时间”，也有了护栏指标“注视时间”，接下来要怎么办？

构建、试验和迭代

在 Meta，几乎每个产品团队都会使用试验加数据驱动的流程推进功能发布和迭代。但对于这些内部辅助团队，这样的流程仍然比较新鲜。因此人们需要克服一系列产品团队根本不需要考虑的挑战（样本量、随机化、网络效应等）。研发人员通过运行网络实验积累起数据基准，并利用技术减少方差、增加样本量。事实证明，这些努力都是值得的——通过奠定坚实的试验基础，使得研发团队最终拿出了具有积极影响且行之有效的新一代代码审查方案。

试验过程：根据对代码审查意义和体验设计的假设，选择了目标指标和护栏指标。此外还制定了一套选择不同实验单元以实现随机化抽样的机制，包括用户集群的随机化。

建立“下一可审查 diff”的概念

Meta 技术研发团队表示，关于这个概念的灵感，来自视频流服务。由于每集视频之间会无缝过渡，所以流媒体服务平台上的观看体验总是丝滑顺畅。那能不能把同样的体验引入代码审查当中？通过 diff 队列，他们建立起了类似的 diff 审查流体系，鼓励审查者们充分利用自己的时间和精力。

于是乎，“下一可审查 diff”的概念由此诞生。研发团队使用机器学习识别出审查者当前最可能想要审查的 diff，并在其完成当前代码审查之后，立即把感兴趣的下一 diff 呈现出来。通过这种方式，我们就能轻松把 diff 审查循环起来，同时避免审查者接触到与其不相干的 diff。

新方案上线之后，研发团队发现，日均审查操作（包括 diff 接纳量、提交量等）总体增长了 17%，而使用此流程的工程师们执行的审查操作比未使用的审查员多出 44%！

改进审查者匹配效果

可以看到，新方案的关键在于为 diff 选择适当的审查者。提交者当然希望审查者能够更好、更快地审查自己的代码，特别是要得熟悉相关 diff 的内容和作用。从以往的情况看，Meta 的审查者推荐器会根据一组有限数据给出匹配建议，但这往往无法适应新 diff 的需要，而且在工程师们轮换岗位后又得重新适配。

为此，研发团队建立了新的审查者推荐系统，将工作时间感知和文件归属信息结合起来，这就让有空审查 diff、擅长审查特定 diff 的审查者更可能被选中。我们重写了建议支持模型，添加了回溯测试和自动再训练等功能。

结果就是，一天之内 diff 审查量增加了 1.5%，而且前三条推荐的准确率（即实际审查者来自前三条推荐）的概率也从不到 60% 增长至近 75%。除此之外，新模型还将推荐速度（第 90 百分位延迟）提升了 14 倍！

用 Nudgebot 解决 Diff 积压问题

我们知道工程师们最不喜欢的就是 diff 积压问题。这不仅让人不爽，而且审查速度过慢还会令代码过时，导致开发者在不同上下文间来回切换、影响整体生产力。为了解决这个问题，Meta 研发团队构建了 Nudgebot，其灵感来自微软所做的相关研究。

对于需要额外长时间审查的 diff，Nudgebot 会首先确定最适合的审查者子集，然后向他们发送一条聊天 ping，其中包含 diff 的部分上下文和快速跳转至审查流程的操作选项。

Nudgebnot 试验也取得了不错的效果。所有 diff 的平均审查时间缩短了 7%（不含周末时段），审查周期超过 3 天的 diff 比例也下降了 12%。

目前此功能已经单独发布：

https://users.encs.concordia.ca/~pcr/paper/NudgeBot2022FSE-preprint.pdf

这里就是审查者在屏幕上看到的积压 diff 通知，下方还有“稍后提醒我”按钮。

审核编辑 ：李倩