Skip to content

代码审核/ Code Review

代码审核标准

简单的检查自动化

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

控制每次 review 的代码量

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

使用异步的工作流

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

在合并到主干之前进行 review

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

作者应该提供清晰的CR需求

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

所有人的代码都要经过 review

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

从正面看待在 review 中发现的问题

当发现一个错误时,并不应该看作是一个人犯了错被另一个人发现了,而是两个人配合改进了代码、避免了错误。

循序渐进

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

代码评审的结果

评审的结果根据反馈出来的这是什么鬼的数量来进行评级

评审步骤

  1. 根据函数来进行评审

在尚未进行所有的评审前, 根据给定的功能点对所有的函数进行逐一的审核, 在审核的过程中, 暴露问题, 然后对问题进行解决

2. 根据追加进行评审

版本对比进行审核

3. 根据需要进行评审

提交需要的标识

Reviewed 代表已经评审过
Reviewed 代表已经评审过
needReview 代表需要评审, 并说明需要评审的内容
needReview 代表需要评审, 并说明需要评审的内容

参考文章