如何做好 Code Review？

1. 背景

最近随着交易业务快速扩展，研发组内新项目及新成员越来越多，如何做好 Code Review，把控研发人员开发代码质量很是关键。

对于大部分业务团队，谈到 Code Review 就会面露哀状：

“上线时间倒排，研发工期这么紧，连码代码的时间都不够了，你还要我 CR？”

“上版的需求，这版就变了，代码生命周期太短，烂就烂吧，反正能用就行啦”

2. 抛出问题

下面分几个方面来分析下 Code Review：

• Code Review 有没有用？

• Code Review 中的问题如何解决？

• 如何做好 Code Review？

3. 分析问题

1）Code Review 有没有用？

Code Review 的好处不言而喻。主要让你的代码可以更好的组织搭建，有更高可读性，且更容易维护，同时可以知识共享，相对而言，找 Bug 并不是那么的重要。

总结一句话，Code Review 可以直接影响你的工程能力。

2）Code Review 中的问题如何解决？

Code Review 中的主要问题：

编码质量较差

原因可能是对业务不熟悉，对语言应用技巧不熟悉，也可能对公司、部门编码规范不熟悉等等，有些问题如果没人及时提醒纠正的话，只会造成在错误的道路上越走越远。

自己承担还是指导他人?

Code Review 是一个学习过程，将自己的一些经验指导给新人，从长远来看，是在“复制”你的生产力，一个人能力再强，也不可能包揽所有的任务，团队协作也是研发人员需要注重培养的软素质。

主要 Review 什么？

编码风格，大家约定俗成的规范准则，从新人开始一步步坚持下去；

代码可读性，代码写出来是叫别人可以读懂的，而且是易读的；

全面性，业务实现异常情况考虑不全面的问题，需要老工程师指导，以免造成线上故障；

不良代码或架构，错误的代码实现、功能函数抽象以及文件组织等，都需要尽量保持整个代码库的风格一致。

3）如何做好 Code Review?

Code Review 机制一定是要与团队规模和项目节奏挂钩的。

Code Review 频次如何控制？

研发前期需要技术方案设计评审，日常 Code Review 保证开发过程中代码质量，研发完成后项目 Code Review 是为了呼应前期评审过的技术方案，确认哪些方案变更了，是由于什么原因等等。

如：大型项目，每天 Code Review 一次；小优化需求，merge request 时候 Code Review 一次即可。

Tips：Code Review 一定要尽可能前置，防止测试后改动问题造成影响。

Code Review 时间如何控制？

一次不要检查过多代码，控制在 1 小时以内，一个研究机构调查指出，太多信息或者 60 分钟以后，发现缺陷的能力就会降低。

作者在审核前需要注释源代码

在他人评审之前，自己 Review 一遍实现思路，说不定会有意外收获呢。

使用 Checklist

可能团队内人员会犯同样的错误，一遍遍重复查找费时费力，应该整理核对 Checklist 来缩减经常出现的错误的排查时间，同样 Checklist 也有利于问题统计和跟踪改进结论。

改进问题要及时

争取当天问题当天解决，同时 Code Review 新问题之前，先回顾一下之前遗留问题是否修复，做到 Code Review 行之有效。

培养积极的 Code Review 文化

Code Review 是团队提高代码质量的机会，也是互相学习的过程；建立接受他人评审的潜意识，我的工作产出是需要其他人 Review 的，这种自我激励会自然的要求自己产出更优秀的代码。

4. 写在最后

作为研发工程师，首先要对自己负责的业务和代码负责，这个与医生、教师的岗位职责是一样的。如果开发没有标准，对应该高标准的东西一味妥协，自己的标准一降再降，到最后吃亏的还是自己。

作者介绍：

张欢，平台交易事业部，2017 年 9 月加入贝壳找房，任职 PHP 资深研发工程师，目前负责交易 C 端 &内容库 &指标平台方向研发工作。

本文转载自公众号贝壳产品技术（ID：gh_9afeb423f390）。

原文链接：

https://mp.weixin.qq.com/s/Taze_uNtgZ7jI_qLnxgLDA