关于code reiview

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

1、建立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），至关方便、快捷。

2、作review要方便

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

3、被review的change要靠谱

你必须在发出review以前，先review本身的代码 - 编译过了吗，回归测试过了吗? 新feature功能实现了吗？bug真的fix掉了吗？ 本身啥都不作，写完代码就发review，而后指望别人可以帮你发现问题（把别人当你的编译器，测试工具？）是很是不负责任的作法，尤为是对本身的不负责，长此以往，你在team中名气大臭，终将失去全部人的信任。

 

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

1、威慑

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

2、把关

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

3、学习

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

4、通知

让整个team的人知道将有这么个change，咱们的作法是建立一个mailgroup：team-cr，把team中每一个人都加进来，而后每一个review都cc这个组 - 而后对于那些有时间、有须要的同窗，就能够监控这个组的邮件。