如何有效地做 Code Review

By on

上次在「为什么每个团队都需要 Code Review」中讲了 code review 在开发中的重要性。这次说一说怎么才能让 code review 有效发挥它的作用。

使用方便的工具。要在团队中成功推行 code review,有好的工具是很重要的。谁都不愿意在工作中加入繁琐的过程,所以如果要让人接受一个新的步骤,最好让它有尽可能好的体验。在我用过的开源 code review 工具中,Phabricator 是最完善的。Review Board 应该也是不错的选择,只是我很久没实际用了,不知道最新状态。GitHub 在支持 side-by-side diff 后,它的 pull request 也提供了很好的 code review 体验,唯一不足的是无法从机制上强制所有 commit 都经过 pull request 的过程。

把简单的检查自动化。有很多检查是可以自动化的,比如一些风格规范(缩进、空行、行尾空格、命名等),这类问题应该尽可能写脚本检查。一方面可以让负责 review 的工程师把更多注意力放在更高层面的问题上;另一方面,从接受 review 的人心理上说,由程序提出这些细节问题比让另一个人来挑刺要更容易接受些。当然,这并不是说人工 review 的时候应该忽略细节问题。

控制每次 review 的代码量。每次 review 包含 200 行左右代码是比较理想的,最多不要超过 400 行。因为如果代码太多,review 的人容易因为注意力分散而忽略一些问题,另外也可能让时间拖得过长。因此,开发的时候需要把大的改动分解成多个小的步骤,每完成一个步骤就提交一次 review。

使用异步的工作流。这和上一点是相关的,当你需要把一个改动分为相互依赖的多步时,不应该因为等待 review 而 block 住自己的工作。在当前分支等待 review 时,可以从这个点开一个新的分支继续开发,之后再把 review 完的分支 merge 进来。

作者应该提供清晰的 commit note。Code review 的重要作用之一是同事间的交流,每个 commit 的 commit note 很重要也很影响 review 的效率,应该包含这个改动的目的,以及实现方式的概述。如果使用的 review 系统支持对 review 本身的描述(如 GitHub 的 pull request),那么应该写清楚作者希望 reviewer 重点关注的问题。

在合并到主干之前进行 review。有的人主张小团队应该做事后的 review,因为这样效率更高、更「轻量」。事实上,这样并不会减少工作量,并且如果工作流安排合理,事前 review 并不会导致效率降低。从心理上说,代码并合并到主干之后往往就意味着「完事了」,在时间比较紧张的时候很难坚持 review 所有代码。所以应该把 code review 作为代码合并到主干前必过的一道关口。

所有人的代码都要经过 review。Code review 并不是资深工程师对初级工程师做的事情,而应该全员平等参与,每个人都会有所收获。关于这方面在上一篇「为什么每个团队都需要 Code Review」里也有提及。

关注设计方面的问题和客观的规范,避免在主观意见上争执。Code review 的讨论应该专注于设计层面的问题以及在团队中有明确共识的规范(代码风格,测试覆盖等),而要避免在一些主观意见的分歧上浪费时间。这也意味着应该在一些本身不重要,但很影响一致性的细节上尽早达成有共识的规范,如缩进方式,括号的位置等等,避免在 review 中去争论这些问题。

从正面看待在 review 中发现的问题。当发现一个错误时,并不应该看作是一个人犯了错被另一个人发现了,而是两个人配合改进了代码、避免了错误。

Review 所有的代码,包括很简单的改动。每一个 commit,无论多小都应该经过 review。一方面,很难界定什么算简单的改动,如果一行的 commit 不用 review,那两行是不是差不多同样简单,三行呢?另一方面,我已经不记得自己曾有多少次觉得「这个改动太简单,不用跑测试就可以提交了」,然后很快因为测试通不过而很尴尬地被别人 rollback。所以无论多小的改动都应该有测试、都应该通过 review。

循序渐进。如果现在完全没有做 code review,那么到整个团队都能严格有效地进行 code review 是一个循序渐进的过程。如果你所处的角色无法很快改变团队的工作方式,那么可以从把自己的代码发给别人 review 开始,实际可见的价值是最有说服力的。

Measurement of Code Quality

Updated