前文

身为一个程序员，我们的工作内容离不开Coding，当然也离不开Code Review。

那么Code Review能给我们带来什么？

发现潜在的Bug，避免不合理的设计，统一代码风格，提升代码质量……这些都是Code Review能给我们带来的收益

既然Code Review能带来这么多益处，那么我们该怎样去进行Code Review呢？

以下则为我从学生时期到工作时期进行Code Review工作积累的一些经验和方式

Code Review外援

纯粹通过人工去进行Code Review可能会存在一些容易遗漏或不易察觉的地方，例如代码重复率或Shadow Param等

这时通过Sonar等工具进行辅助可以避免遗漏，并对代码质量进行统一管控

三思而行

当我们实现一个中等的功能时，有些新人发现提交的MR/PR收到了一堆Comment，必须从代码架构上动刀

这很大概率是因为没有做好一开始的架构设计，当边想边做写完之后才发现有一堆问题

所以我们在Coding之前需要对自己的设计进行梳理，设计思路得到评审后再进行开发，必定事半功倍

自测100%

Code Review时，我们的Reviewer更多的是对架构设计和代码规范做审核，因为很多时候Reviewer可能是其他业务线的同学，而并不是负责该业务，所以对于功能上的自测和测试用例覆盖需要在提交PR/MR前做好

此外，尽量在PR/MR的描述中增加功能截图、测试覆盖报告等内容，用于辅助说明

阶段性PR

通常一个需求开发时，可能会因为需求的规模而影响PR的大小，如果一个PR过大，则意味着有大量的文件变动，那么此时Reviewer是非常痛苦的。但如果我们把一个PR拆分成多个阶段，例如有一个文件收取服务的PR，把整个PR拆分为接收功能Part和处理数据Part，这样会使Review更轻松，也更能发现潜在的问题

评论分级

在多次Review和被Review的过程中，我逐渐发现了一个问题，很多时候我们只是评论了一句话，但是被Review的同学不清楚表达的含义，是否必须修改

这时我们可以对评论进行分级处理，不同的等级使用不同的标识，例如

• [mountain] — 致命的问题，需要立即修改，会影响整个服务

• [boulder] — 严重的问题，不修复不能通过审核，不影响其他服务，比如性能问题

• [pebble] — 一般的问题，不影响当前合并，但需要列为TODO项，比如测试用例缺失

• [sand] — 轻微的问题，无需列为TODO项，例如重构提高可读性

• [dust] — 无关紧要的问题，例如命名和代码风格

以上是Netlify公司对于评论分级的规范，我们可以做一些本土化的适配，并优化一下

• [fatal] — 严重的错误，影响整体服务，或者影响局部服务

• [must] — 必须的修改，例如设计不合理，测试用例不通过

• [optional] — 可选的修改，不影响功能，可能为代码风格建议或用例缺失

• [doc] — 补充注释说明，通常用于较长的功能函数，或复杂晦涩的逻辑

• [confuse] — 对代码不理解，需要提起合并者进行解答

类似这样，在每条评论前增加标识将更直观的了解原意，提高Review效率

满分示例

有些时候我们提交的PR可能比较急迫，例如17:00提交，第二天10:00就需要合并上线。这时如果我们面临一大堆Comment，肯定会很绝望。此时，如果我们对需要变更的代码直接写好建议示例，将会大大缩短被Review同学的修改时间

例如以下场景，有同学不太熟悉Go的可变参数特性，提交了一段这样的代码

func foo(a int, b []interface{}) bool {
     ......
}

此时我们只是提了一下使用可变参数，然后那个同学花了5分钟才了解它的用法，如果此时我们直接用以下的方式评论

- func foo(a int, b []interface{}) bool {
+ func foo(a int, b ...interface{}) bool {
    ......
}

这样可能只需要5秒钟就能完成修改，极大的提升了效率

当然我们也不要把示例代码写的太多了，如果你的示例几乎把原作者的变更都覆盖了，那么表示你不认为他们能写好代码

结语

Code Review是开发过程中必不可少的环节，如果你还没开始，不妨现在开始实践；如果你已经开始了，但没有收获到好的效果，可以自问一下是否把Code Review作为一种开发文化而非一项冰冷的制度

以上，希望在看的你有所收获