先谈谈三个code review的关键因素：

一、创建review要简单

code reivew是一个程序员日常工作中经常做的一件事，理论上来讲，任何一个将要submit到SCM的change，都必须经过peer review。如果创建一个review要傻了吧唧的打包代码，发送邮件，或者shelve一个changelist，再发信告知changelist number，或者进入某个比较先进的code review系统（比如crucible）手工创建一个review，这些步骤都太过繁琐，任何一个懒惰的程序员都不会有耐心来做这种事，更别说日复一日的做这种愚蠢的事了。

我们需要的是一键式创建review - 一个按钮，搞定！ 比如我以前公司用一个p4插件，直接右键一个pending changelist，就可以创建一个code review(code collaborator)；我现在公司则更加全面，更加彻底，提供了一个命令，可以cover不同的scm，不同的code review系统（支持crucible，gerrit），相当方便、快捷。

二、做review要方便

review的过程，是一个就代码相互交流的过程，为了使这个交流更加高效，我们需要明确知道在讨论的是哪一行代码 - 显然，用邮件是一件相当愚蠢的事情，就像有些人吹嘘用notepad写代码一样。现在市面上这样的系统非常多了：我用过的就有code collaborator, crucible。可以直接就某一行代码开展讨论，并及时邮件通知。

三、被review的change要靠谱

你必须在发出review之前，先review自己的代码 - 编译过了吗，回归测试过了吗? 新feature功能实现了吗？bug真的fix掉了吗？ 自己啥都不做，写完代码就发review，然后期望别人能够帮你发现问题（把别人当你的编译器，测试工具？）是非常不负责任的做法，尤其是对自己的不负责，久而久之，你在team中名气大臭，终将失去所有人的信任。

 

再谈谈四个code review的重要作用：

一、威慑

这是我感触最深的一点：知道自己的change会被review，那么在做这个change的过程当中，你就会比较负责任的往代码全局最优的方向去修改，而不是为了临时解决自己当前的问题选择一个比较丑陋的方案 - 因为你知道，即使你选了这个丑陋的方案，然后做了编译测试，发出review之后还是会被人以正当的理由退回来，与其浪费那么些时间做无用功，还被人很没面子的退回来，还不如一开始就做的漂漂亮亮的，久而久之，这种追求最优的习惯就会养成。

二、把关

别人能帮你发现你视觉盲点中，或者视野范围外的一些问题。毕竟，多个人多双眼睛，尤其对于比较senior，或者该领域的专家来说，总能对你有所裨益！

三、学习

别人能从你的代码中学习你优秀的解决问题的思路，写代码的技巧，这是team整体提升的一条非常好的道路。事实上，培养新人的一个方法，除了让他fix bug之外，就是让他review代码，当然，一般是作为副手。

四、通知

让整个team的人知道将有这么个change，我们的做法是创建一个mailgroup：team-cr，把team中每个人都加进来，然后每个review都cc这个组 - 然后对于那些有时间、有需要的同学，就可以监控这个组的邮件。