InfoQ6 个实用的 Code Review 实践技巧

作者 | Alejandro Lujan
本文最初发布于 Shopify 博客，
经原作者授权由 InfoQ 中文站翻译并分享。
Code reviews 是打造高效团队的重要方面，这已经成为共识。关于这个主题，有许多文章曾经讨论过，比如这篇论文——《 An Empirical Study of the Impact of Modern Code Review Practices on Software Quality 》。现实中，许多企业的无数团队都进行过某种形式的 code reviews 。
而实际情况是， code reviews 刚开始时，人们的激情高涨，之后， code reviews 则流于形式，或者要么反馈不清晰、要么让人难以执行。长久以往，这让团队错失了加快学习、分享知识的机会，最终难以提高代码的质量。
在 Shopify ，我们不仅立足长远，而且希望追求发展更快。以我们的经验来看，优秀的 code reviews 实践对工程师的成长和我们所打造的产品质量有着巨大影响。
噩梦般的编码经历这样一个场景相信很多人都很熟悉：
你刚刚加入一个新团队，领导很快给你分配了一个编码任务。作为新人，你特别想表现自己，因为你想秀一下自己的编码水平。于是，你接下来做了这些事：

你为了完成任务疯狂地敲了三周代码；
你将一个包含大约 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你听过造一辆汽车与画一辆汽车的比喻吗？这个比喻是这么说的：