下午 3 点代码审查规则

最近，我在当地一个工程小组中就我们团队所做的软件实践进行了一次演讲，令我感到惊讶的是，有这么多人回来后说，他们非常喜欢我们为加速整个拉取请求/代码审查协议所做的这件小事。

实际上，这个想法非常简单：

每天下午 3 点是 Code Review 时间。

但是，等等，这到底是如何实现的呢？

对我们来说，这实际上意味着下午 3 点，我们会在每个人的日历上安排一个固定的 1 小时时间段。这迫使每个人都停下手头的工作，把这段时间专门留给那些等待宝贵代码审查反馈的同事。正式分配这段时间不仅能帮助大家记住，还能让他们意识到代码审查对于健康的交付流程至关重要。

在进行这种实践之前，我们在代码审查方面遇到了一些问题：

人们忘记了代码审查。最初，我们尝试坚持督促同事花一些时间进行代码审查。坚持下去。起初这招有效，但很快双方就都忘了。被审查者会跳到其他故事里，忘记提醒审查者采取行动。另一方面，审查者会本能地等待被催促，认为否则这个拉取请求就没那么紧急了。
我们通过两次已获批准的代码审查来控制 PR 的门槛。有时，那些对自己的用户故事过于深入的人会偷偷摸摸地等待另一位审查者进行初步审查，希望在初步细节整理好后，自己可以稍后再进行审查。当然，有时两位审查者也会尝试玩这个把戏。你知道结果会怎样。
由于上述几点，大多数用户故事在冲刺后期才得以关闭。燃尽图通常呈现出一个大台阶的形状。但更重要的是，随着冲刺接近尾声，人们会急于让自己的故事获得评审，同时又被迫评审其他故事，并匆忙修复评审意见。这通常会导致代码质量低于预期，无法进入主分支。
作为一名工程主管，我会密切关注评审。我总是会查看关键评审并给出反馈，但我会将审批权交给团队。很多时候，我被要求在还没有人看过故事的情况下进行评审。通常，评审员这样做是为了尝试解决一些由于我们的工作方式而自然卡住的问题。

现在新政策实施后，我相信我们帮助大家养成了更好的习惯。以下是一些关于团队执行该政策的评论以及一些个人观察：

下午 3 点的审查政策并不妨碍人们在其他时间进行代码审查。人们可以更早或更晚进行代码审查。但至少在下午 3 点到 4 点之间，他们需要停下来进行这项工作。
代码审查时间（我们通常为一小时）可用于单独或小组审查。现在，被审查者和审查者通常会参加结对审查会议来讨论变更。这加强了一些良好的互动，因为以前没有固定的会议时间，而且人们很少结对。
如果某人当天没有什么需要复习，那么这段时间可以用来做其他任务。
自从制定这项政策以来，我们设法将开放 PR 的队列控制得更短了。燃尽图仍然有步骤。说实话，但这些步骤不像以前那么陡峭了，尤其是在冲刺的末期。
具体时间完全是随意的。我们之所以选择下午 3 点，是因为我们认为这个时间点大家已经在日常工作上投入了大量精力，所以是切换工作内容的好时机。
最后，现在我需要审核的 PR 少了很多。我可以专注于关键的 PR，而不用为了加快进度而被要求审核。

我觉得这个技巧并非原创。平心而论，这个想法是从某个地方冒出来的，我发誓我记不清了，我们只是把它正式定型成了一条规则。那就是下午 3 点的代码审查规则。

那你呢？你用了什么技巧来加快代码审查速度？很想向大家学习。