PS：原创文章，如需转载，请注明出处，谢谢！
本文地址：http://flyer0126.iteye.com/blog/2426055
一、背景
最近随着交易业务快速扩展，研发组内新项目及新成员越来越多，如何做好Code Review，把控研发人员开发代码质量很是关键。
对于大部分业务团队，谈到Code Review就会面露哀状：
“上线时间倒排，研发工期这么紧，连码代码的时间都不够了，你还要我CR？”
“上版的需求，这版就变了，代码生命周期太短，烂就烂吧，反正能用就行啦”
二、抛出问题
下面分几个方面来分析下Code Review：
* Code Review有没有用？
* Code Review中的问题如何解决？
* 如何做好Code Review？
三、分析问题
1、Code Review有没有用？
Code Review 的好处不言而喻。主要让你的代码可以更好的组织搭建，有更高可读性，且更容易维护，同时可以知识共享，相对而言，找Bug并不是那么的重要。
总结一句话，Code Review可以直接影响你的工程能力。
2、Code Review中的问题如何解决？
Code Review中的主要问题：
a. 编码质量较差
原因可能是对业务不熟悉，对语言应用技巧不熟悉，也可能对公司、部门编码规范不熟悉等等，有些问题如果没人及时提醒纠正的话，只会造成在错误的道路上越走越远。
b. 自己承担还是指导他人?
Code Review是一个学习过程，将自己的一些经验指导给新人，从长远来看，是在“复制”你的生产力，一个人能力再强，也不可能包揽所有的任务，团队协作也是研发人员需要注重培养的软素质。
c. 主要Review什么？
编码风格，大家约定俗成的规范准则，从新人开始一步步坚持下去；
代码可读性，代码写出来是叫别人可以读懂的，而且是易读的；
全面性，业务实现异常情况考虑不全面的问题，需要老工程师指导，以免造成线上故障；
不良代码或架构，错误的代码实现、功能函数抽象以及文件组织等，都需要尽量保持整个代码库的风格一致。
3、如何做好Code Review？
Code Review机制一定是要与团队规模和项目节奏挂钩的。
a. Code Review 频次如何控制？
研发前期需要技术方案设计评审，日常Code Review保证开发过程中代码质量，研发完成后项目Code Review是为了呼应前期评审过的技术方案，确认哪些方案变更了，是由于什么原因等等。
如：大型项目，每天Code Review一次；小优化需求，merge request时候Code Review一次即可。
Tips：Code Review一定要尽可能前置，防止测试后改动问题造成影响。
b. Code Review 时间如何控制？
一次不要检查过多代码，控制在1小时以内，一个[研究机构] 调查指出，太多信息或者60分钟以后，发现缺陷的能力就会降低。
c. 作者在审核前需要注释源代码
在他人评审之前，自己Review一遍实现思路，说不定会有意外收获呢。
d. 使用Checklist
可能团队内人员会犯同样的错误，一遍遍重复查找费时费力，应该整理核对Checklist来缩减经常出现的错误的排查时间，同样Checklist也有利于问题统计和跟踪改进结论。
e. 改进问题要及时
争取当天问题当天解决，同时Code Review新问题之前，先回顾一下之前遗留问题是否修复，做到Code Review行之有效。
f. 培养积极的Code Review文化
Review是团队提高代码质量的机会，也是互相学习的过程；建立接受他人评审的潜意识，我的工作产出是需要其他人Review的，这种自我激励会自然的要求自己产出更优秀的代码。
四、写在最后
作为研发工程师，首先要对自己负责的业务和代码负责，这个与医生、教师的岗位职责是一样的。如果开发没有标准，对应该高标准的东西一味妥协，自己的标准一降再降，到最后吃亏的还是自己。