关于Code Review, 从coolshell的一篇文章所想到的.

酷壳( coolshell.cn )是我个人非常喜欢的一个技术博客,创办者陈皓( @左耳朵耗子)在这个博客里面提供了很多非常有营养的文章,没看过的程序员朋友一定要看一看.

这篇博文源自于这篇文章:

从Code Review 谈如何做技术

看到作者这种大牛在阿里这种以工程师文化闻名的公司推行code review的时候遇到的种种阻力,想想自己从抵触到接受,到现在认为review完的代码才能commit,整个过程说出来我觉得多少还是有些意思的.

在工作的前5年里(shame),我基本上没有做过任何形式的code review,无论是让别人review我的代码,还是review别人的代码.原因太多了,公司没有强制规定,小组也没有形成氛围,在这种情况下,贸然请别人花时间review自己的代码,别人是不一定乐意的,自己自告奋勇review同事代码更是一种类似挑衅的行为.当然,如果有一段代码的处理逻辑非常复杂,我没有信心能够独自一人很顺利搞定的时候,我会向经理提出申请,邀请一个同事来和我一起写,对,就是类似敏捷提倡的那种”结对编程”的模式,只是多数时间是我在写,他则在旁边跟我聊聊天,在我脑子发热的时候一语中的的指出我的list中包含的到底是什么样的数据结构.也就是所谓的”当局者迷,旁观者清.”.一来这种非常复杂的开发工作不会天天有,而且开发时间不会特别长(一般不超过半天),二来坐在旁边看别人写代码其实是一个稍微轻松的事情,因此这种举动并没有引来经理和同事的反感和抵触.

首次接触”疑似”review是在前一家公司,我们开发的整套环境都是一个老家伙带着团队搭的(天知道他们积累了多久才搞了这么多玩意),从vim的配置,php开发框架,一直到上线分发的脚本都有,其中上线前最重要的部分就是将最新版本和线上版本的代码依次做vimdiff,只有都确认ok的时候才会上线.我所在的team只有我和另外一个老家伙具有上线权限.因此每次上线前,一个一个文件的查看diff,确认新的修改ok就成了必然的工作.当然,最开始我对此感到的是好奇和新鲜(从eclipse插件开发到php网站开发,一个月时间,如此跨度,不新鲜才怪),后来在发现了几个明显的拼写错误和几个隐蔽的逻辑bug之后,我意识到这么做原来真的可以发现这么多问题,就对这件事情逐渐重视起来.当然,甚是土鳖的我,当时必然是不知道review board这种高级玩意的存在的.

从前公司离职加入现在公司之后,开发语言从php又换回了老本行-java.我作为一个新人,首先肯定还是适应新的团队和环境,因此review这种事情就作为内心中一个隐隐的向往,就给放下了(其实作为程序员,我心中已经有很多类似的隐隐向往了,比如”我一定要重构XX模块,我一定要开发一个XX工具,我一定要努力把数学水平提高点….”,多一个不多).后来公司来了一个CTO,当然,还来了很多高大上公司的天才,如果没记错的话,Code Review是作为新技术管理团队的三把火工程提出来的.当然,经理层中有没有人为了这个事情把CTO微博拉黑我是不知道得:-),但是下面的一线程序员议论的还是有一些,讨论的主要内容和上面陈皓文章中写的差不多,人手不够工期紧blabla,但是讨论归讨论,毕竟因为这个事情跟经理闹翻的事情是不会有人做的.我在配置了reviewboard之后,立刻爱上了这个玩意.我擦原来还有这么高大上的东西.当然,作为三把火工程的配套工程,新团队还给了一些suggestion,比如关于代码规范性方面的建议,比如提review应该小步快跑,比如最好同时提给2个以上的人看等等.然后就是近似强制使用到现在.

个人总结一下code review带来的好处:

1.能缓解技术团队管理上的单点问题.共同维护一个大系统的程序员团队很容易成为某人负责某个模块的形式.不可否认这么分配效率是最高的,但是风险也很大,原因很简单,Single Point.纵然管理上一直在提敏捷,说所有人对所有代码负责,但是最终的结果基本上就是没人对别人的代码负责.但是如果强制的去要求团队成员轮流换模块开发,那么整个团队的开发效率又会有问题(尤其是项目规模稍大,且业务逻辑非常复杂的情况下,要每个人都非常清楚所有模块,确实不太可能).那么采用codeReview的形式,将2~3人分组,一个主力开发,另外的人负责review,那么至少会有人对代码熟悉.单点情况能缓解很多.

2.对于个人来说,当我知道我的代码必然会被别的同事审阅的时候,那么在无形中我就会更认真的对待.比如在变量命名上更仔细,或者在代码结构和运行效率上考虑的更多.那么当我review别人的代码的时候我也会更加注意同事的代码有没有疏忽和遗漏.当然,在经历了前几次扭捏之后,现在大家在review的时候提问题已经脸不变色心不跳了,毕竟都是就事论事,也算是加深了同事之间的相互信任吧.

3.有助于培养团队整体的代码风格.每个人都有自己的代码风格,那么某种自己熟悉的写法如果受到团队其他成员的一致差评(破窗户被第一次发现),那么这个问题下一次一定会被纠正过来的(立刻被修补).反之,阅读别人代码时,我也会有惊喜:原来还有这么牛叉的api和用法, 下次我也用!

 

对于还没有接触过code review的同学,我再给出一点小建议:

1.无论团队有没有code review的习惯,自己在commit之前,重新diff一遍,认真的读一遍自己的代码是绝对有好处的.

2.在团队中开发中,自己可以偷偷的check下来同事的两个相邻的版本,然后看看diff,一来可以了解一下业务,二来培养一下自己阅读代码的水平,毕竟读开源代码所花费的精力远超过阅读自己天天接触的系统的代码.

One thought on “关于Code Review, 从coolshell的一篇文章所想到的.

发表评论

电子邮件地址不会被公开。 必填项已用*标注