关于code reiview

先谈谈三个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这个组 - 然后对于那些有时间、有需要的同学,就可以监控这个组的邮件。

posted @ 2013-06-23 21:46 lzprgmr 阅读(...) 评论(...) 编辑 收藏

黄将军