我分析了一年的代码审查最佳实践。以下是我学到的。

在过去的一年里，在构建Pullpo的过程中，我一直高度关注一个特定领域：代码审查。我分析并采访了数十个不同规模、不同行业、不同国家的团队，以真正了解代码审查的最佳实践。

为什么？

代码审查很重要。

许多人认为代码审查只是为了改进代码，保证满足不同利益相关者的需求，可能是安全性、可维护性、性能或仅仅是功能，这取决于环境。

但是代码审查不仅仅是为了改进代码，它们很多时候是团队内部开发人员改进和学习新知识的最佳机会。

此外，最近的研究（DORA 2023 报告）证实，改进代码审查可以将软件交付性能提高 50%。您可以点击此处查看我对该报告的总结。

代码审查应该很快。

这至关重要。通常情况下，除非你使用类似SHIP、SHOW & ASK之类的工具（我推荐），否则所有代码审查默认都会被阻止。

也就是说，在更改满足所有要求并获得必要的批准之前，代码不会投入生产。

这一点非常重要：我们应该优化团队交付产品的速度，而不是开发人员编写代码的速度。事实上，这正是 Google 工程实践文档的第一句话。

这意味着尽快回复代码审查消息。

代码审查不应该破坏你的流程。

心流状态是指你高度专注于某项任务的时刻：它可以是设计、编程，或者任何你正在做的事情。一些 DevEx 框架（例如论文《Devex：真正驱动生产力的因素》中提出的框架）将心流状态作为提高开发者生产力的首要任务。

论文《DevEx：什么真正推动了生产力？》中的 Devex 三角

心流状态对于团队的效率非常重要，所以如果你是一名开发人员并且处于心流状态，请尽量让自己保持这种状态，避免切换任务，并尽可能避免中断。

处于心流状态是推迟快速回复代码审查消息的唯一原因。

我很喜欢在 reddit 上找到的这张关于心流状态和中断之间的困境的图片。

感谢nkukard。

沟通很重要。

通常，代码审查都是以书面形式进行的。人类在书面形式下交流会差很多。你的肢体动作和语调都无法表达。因此，误解更容易发生。

这就是为什么一些新的沟通框架正在兴起，例如常规注释。它类似于常规提交，但应用于代码审查注释。你可以在其中明确指定注释背后的意图。例如：

question (non-blocking): At this point, does it matter which thread has won?
Maybe to prevent a race condition we should keep looping until they've all won?

非阻塞意味着该评论不会阻止 PR 被接受。

该领域的其他一些提示包括：

• 提出问题而不是肯定。
• 要友善。
• 如果您资历较深，请花时间进行指导，这将带来巨大的回报。
• 如果您与队友在某个特定主题上意见不一致：
  • 别太介意。
  • 仔细听取对方的解释。
  • 亲自或通过电话讨论，这样更容易实现有效沟通。

PR 应该很小。

PR/MR 应该尽可能小。每次只做一项变更。每次只实现一个目的。

我们都看过这个梗并且知道它是真的：

致谢twitter.com/iamdevloper

如果我们想要保持质量，那么大的变化会使异步代码审查变得非常慢；如果我们想要保持速度，那么质量就会变得非常低。

那么，当任务巨大，需要实施许多变更才能完成，而我们又无法将任务划分为功能性小子任务时，我们该怎么办？

• 堆叠拉取请求。这是一个很好的替代方案。它基本上意味着将任务划分为可评审的（少于 400 个代码）拉取请求 (PR)。这种方法的缺点是，由于这些拉取请求相互依赖，因此第一个分支上的更改也需要更新依赖的分支。

  这一事实可能会让您浪费一些时间通过“合并”或“变基”手动同步依赖分支，这就是为什么会出现一些工具，例如git-town、ghstack或graphite。

感谢McKayla 博士

• 结对编程。一些公司将结对编程作为默认的开发方式。这也意味着代码在开发过程中已经由两个人进行审查，因此您无需在开发完成后进行常规的异步代码审查。

配对注意事项。

过去，一些公认的作者，例如《持续交付》的作者戴夫·法利 (Dave Farley)，提出了一个有争议的观点（阅读视频或此处的评论），即通过 PR 进行代码审查只是一个坏主意。

在此视频中，Dave 提出结对编程是针对每种情况、每种类型的公司、每种类型的开发人员和每种类型的任务的最佳代码审查解决方案。

我关注 Dave，也同意他的大部分观点，但很多时候事情并非非黑即白，而是介于两者之间，取决于不同的因素。配对就是其中之一。

作为一名开发人员，您需要了解自己，以便了解在哪些情况下与哪种类型的人配对以及在解决哪种类型的问题时您会感觉更有效率。

就我而言，通常只有在以下情况下，我才会觉得结对工作富有成效：

• 指导团队中的新人。
• 集思广益，为复杂问题寻找创造性的解决方案。

然而，在结对工作时我很难达到心流状态，正如我们在本文前面所讨论的，心流状态是影响开发效率的一个关键因素。

最后的想法。

• 代码审查需要快速进行，这就是对代码审查消息的快速回复。
• 处于流动状态一定是推迟代码审查消息的唯一原因。
• 沟通很重要。保持友善，认真倾听。必要时，可以面谈或打电话。
• 每个 PR 只有一个目的。小型 PR。必要时，可堆叠 PR。
• 尝试与不同的人结对编程，完成不同的任务。探索结对编程何时对你（以及你的团队）有用。