6 个实用的 Code Review 实践技巧

• 你将一个包含大约 1000 行新代码的 Pull Request 提交评审；

• 你收到两条关于 code style 的评论，以及一个关于评审人表示他看不懂这些代码用途的问题；

• 你修复 code style 并回答评审人的问题，然后评审人通过你写的代码；

• 你把代码分支合并到 Master，双眼紧闭，紧握着拳头，紧咬牙关等待着结果。几分钟后，CI 完成。幸好，Master 没有崩溃。然而…

• 此后 6 个月，你一直战战兢兢，不知道代码何时会崩溃，以及以什么方式崩溃。

你可能经历过上述噩梦般的经历，那我们谈谈怎样改进这个流程吧！

实用的 Code Review 实践

在 Shopify，我们看重交付速度、学习以及长期发展。这些价值观虽然有时会产生冲突，但却引导我们不断尝试许多新技术，并推动团队变革。

我在本文总结了一系列 Shopify 内部使用的实用技巧。借助这些技巧，我们能交付经得起时间考验的有价值的代码。

术语说明：我们将 Pull Requests（PR）定义为合并到基础分支前进行 code reviews 的一个工作单元。Github 和 Bitbucket 的用户对这个术语很熟悉。

将 Pull Request 拆分为较小的代码段

这个方法很简单，可以成为提高 code reviews 工作流程最有用的技术。它之所以有效，主要有两个原因：

• 评审人心理上更容易接受开始和完成一小块代码的评审工作。更大的 PR 自然会让评审人推迟和拖延评审，并且在评审过程中被打断的可能性更大。

• 作为一名评审人，如果 PR 太长，就很难深入进去。要检查的代码越多，我们越需要耗费更多脑力来理解整个代码块。

将 PR 拆分为更小的代码段，让你有更多机会在更短时间内得到更深入的评审。

目前，我们无法设置一个适用于所有编程语言和所有类型工作的通用标准。对于内部的数据工程项目，我们原则上是要将 PR 控制在 200-300 行代码。如果超过这个阈值，我们一般会将它拆分成更小的块。

当然，我们也要注意不要将 PR 拆分得过小，因为这意味着评审人可能需要检查好几个 PR 才能理解整体逻辑。

使用 Draft PRs