聊聊Code Review

本文来自微信公众号：WeCoding

边际效益

在谈论是否应该做一件事时，往往看它的边际效益：在每进行一次Code Review，它所产生的成本和收益

收益

工程师在完成编码工作的同时，除了要交流code，还要分享架构设计，Code Review 正是将交流代码、分享架构模式相结合的的最佳方式

• 知识传播,互相增进代码质量：

• 通过CodeReview，可以把好的代码规范和架构设计传播给代码提交者

• 同时每个人都有知识短板，reviewer也可以学习到提交者一些好的编码习惯和架构设计

• 多人review的同时可以提出自己不同的见解，本身就是思想大碰撞

• 找出潜在的 bug。虽说大部分bug应该在单测阶段、QA测试阶段发现，但提交者和QA很可能对业务细节和技术细节把控不够，并且有些 bug 在测试中很难复现从而造成遗漏；而Code Review 在这方面有好的补充效果。

成本

• 很多团队由于工期紧、需求变更快，只能向排期妥协，长期以往Code Review 就会变样、流于形式。这种情景下CR的作用被严重淡化,还占用了时间

建立高效的Review机制

做好Code Review的关键有两点：

    1、减负，只做适合它干的事；

    2、提高Code Review效率

Code Review 应该讨论的是功能实现、架构设计、代码可用性质量，不应该做以下事情：代码风格和编程规范。如果提交者不是新人，不建议Review把重心放在代码编程规范，这种鬼事情应该交给插件来做。接下来思考如何提高Code Review效率

团队开发规范

这块不同于Java编程规范的东西，更多是组内开发规定。比如使用lombok取代get、set方法；优雅使用mybatis-generator；多个项目不能各自搞含义相同的枚举，维护成本高；拒绝代码冗余等

日渐完善的checklist

对于容易误用的API、名词职责不太匹配等有歧义的代码，是很多新人容易共犯的错误，应该有公用的团队checklist；这样可以减少PR中的一些错误；其次对于工程师，应该有个人cheklist来记录自己的心得，避免同样问题再犯

好的PullRequest概述

提交者可以把Pull request写个简述，别人一看就知道是干啥。review起来效率更高，同时也是对自己开发逻辑的梳理

见名知意的commit

当PR改动较多时，Reviewer需要根据一些commit来分析工程师意图，如果都有一堆类似“add、fix、fix_bug”等无效信息，review起来效率会很低

阶段性Review

在完成架构设计，代码骨架后，应该及时提交 review，以便大家了解设计者的思路。其次可以每完成一个模块时，先找对应的人Review一部分。别开发了两周，Reviewer看到这一坨，无从下眼；此外都开发完了，发现代码要推倒重来，问你奔溃不。

积极推动

reviewer可能会忘了要review代码，提交者应积极推动

长按订阅更多精彩▼

如有收获，点个在看，诚挚感谢