发个无聊的贴子，看看大家怎么看code review的

最近公司在搞流程改进，而code review就不可避免地成了技术小组关心的一个重要问题，因为公司和CMMI一直在推，效果却非常不理想

正是因为我们做的效果不理想，而网上牛人们却在不停地推它，所以，我们就宁可相信这个code review是个很好的东东，是我们自身没有做对而已

下面是我和公司一同事讨论得出的一个方案，供大家参考（我们考虑的重点是可行性、实际效果和执行效率）
1．  开发刚开始的阶段，由TL和PM召集大家坐在一起进行几次review（至少3-5次）
2．  在开发过程中，如果开发人员觉得哪段代码写得不是太好时可以请senior/TL/designer帮忙review
3．  senior/TL/designer在某一模块完成之前，必需完成该模块的review


对方案的一些解释：

1. 第一条的目的是在项目开始的时候，把一些代码规范和参照设计文档写代码的习惯传达给大家
2. 第二条的目的是让开发人员有这样的一个机会请senior/TL/designer来帮忙查看一下代码，提前发现一些问题。这一条需要开发人员的主动性，如果他真的想把代码写好，在遇到问题时，我相信是一定会有这个主动性的。另外，即使开发人员不能提问，那还有第三条来保证代码质量。
3. 第三条的目的是TL/Senior/Designer出于对项目一致性或质量的要求，会去做出review，看代码是否符合设计，是否符合编码规范，是否有哪些写法值得提醒开发人员注意。在这一点上，要求review工作在某一个模块完成的时候同时完成，不应该在开发人员开发完成后再做review，让开发人员把模块都做完后来返工是件不太好的事。这也就要求PM在排计划的时候，一定要给TL/Senior/Designer安排合适的时间来完成review工作

所以，我们必须要有统一、稳定的编码规范(format, 目录结构等)，供review的参考的设计，开发人员提出review的请求后能得到积极的响应，并给出有效的建议

下面的链接是ozzzzzz大师发起的讨论，遗憾的是我不能找到他的那篇关于code review的文章，希望有人能分享一下
http://www.iteye.com/topic/2217

评论

56 楼 raylin 2008-09-05  

关键是Review的 Scope 很重要。大家不妨在这个话题上面探讨下经验。有那些东西值得Review，有哪些东西是不值得去花这个时间去Review的。
公司性质不同也许Review的侧重点也不同。比如外包公司可能文档之类的Review就要求的比非外包公司严格。

55 楼 raylin 2008-09-05  

andyhu1007 写道

code review: 费时，费力，交流麻烦。推荐pair。

code review 还是有必要的。不是所有人都喜欢Pair的。这要看组织文化了。

54 楼 mindxw 2008-09-02  

younggun 写道

xuby 写道

什么pair/review这些方法都不好,好的办法要从中国传统智慧中去寻找.
南北朝时北朝有个皇帝赫连勃勃,要建首都(统万城)的城墙.为了最大程度保证质量,他把团队分为两组,一组施工,一组质监.施工组建完一段墙后,质监组过来做检查,检查办法是用铁枪使劲往城墙上戳,那么结果无非两个,一是把墙戳个坑,或者是墙毫发无损.
对于第一种情况,皇帝的措施是这样的:把施工组的人全部砍头.第二种情况的处理大家可能猜到了,就是把质监组的人杀掉.
采取这种措施的成效非常喜人:近2000年过去了,这个统万城依然屹立不倒.
诸位认为这个质保措施用于软件业,会有什么效果?

你这个方法太极端了，我知道一个比较好的例子是降落伞工厂会让生产工人从自己生产的降落伞中抽出样品来试用。

两位都很极端,也很幽默.
哈哈!!!

53 楼 mindxw 2008-09-02  

kimmking 写道

传统的公司中，pair不可想象，

试问：领导者如何会乐意见到每时每刻都有一个人在“闲”着！

理想的pair还是很不错的选择,问题是pair之间的互动并不像某些人想象中的那样,这种情况下,你怎么办?

52 楼 RCFans 2008-09-01  

CMMI 3级就会制定标准的Code Review范本，照着上面的做就是了，感觉还很有用的

51 楼 香克斯 2008-08-29  

fengzhang 写道

我看了大家的讨论，我个人认为大家对于code review的有一些理解是有偏见的。根据我的经验，code review的要求如下：
一、review执行者要求
   1.精通项目组所使用的技术
   2.了解整个系统或者一个模块的业务过程
   3.具有很强的责任感和耐心
二、code review的基本要求
   1.找出不符合项目规范的代码
   2.找出可能在不同的情况下会出现异常的代码
   3.是否是完全符合业务要求
   4.是否对其他的机能造成影响
   以上4点中，后两点是最重要的，但是好多公司和个人往往把1，2点作为重点，也就导致大家认为更本没有必要的想法了。对于业务的检查是没有任何工具能够代替的。

这个靠人来看？我很佩服你们做这个事情的人

50 楼 jwnest 2008-08-28  

既然名字是code review，就不要太涉及业务相关的东西，把关注点集中在coding相关的方面来，除了1，2条外，我觉得最重要的是代码的风格和一些好的习惯，比方说如何提取一个方法，如何对代码进行refactor和抽象，要通过revie潜移默化的提高整个team的代码水平，我觉得这个才是code review的最终目的。
至于需求相关的东西，其实不应该在code review中解决，应该是测试关注的问题。

49 楼 gurudk 2008-08-27  

fengzhang 写道

我看了大家的讨论，我个人认为大家对于code review的有一些理解是有偏见的。根据我的经验，code review的要求如下：
一、review执行者要求
   1.精通项目组所使用的技术
   2.了解整个系统或者一个模块的业务过程
   3.具有很强的责任感和耐心
二、code review的基本要求
   1.找出不符合项目规范的代码
   2.找出可能在不同的情况下会出现异常的代码
   3.是否是完全符合业务要求
   4.是否对其他的机能造成影响
   以上4点中，后两点是最重要的，但是好多公司和个人往往把1，2点作为重点，也就导致大家认为更本没有必要的想法了。对于业务的检查是没有任何工具能够代替的。

我组织review的目的也是意在3，4条，但是往往真正满足review资格的人少，或准备不充分，导致3，4条很难深入，最后就变成1，2条流于形式了，这也是我头痛的问题。

48 楼 alfred.w 2008-08-26  

pair 个人觉得和code review根本不是相同的用意。pair的人一般是水平相近的人，那么做review进行改进的空间受到了限制，再者，pair的时候两个人是相同的工作内容，code review我觉得重要的用意不单单是检查排版和命名以及某个方法是不是好，更重要的是站在更高一点的高度，整体对代码做review,找出坏味道，减少项目风险，和以后维护的难度，让代码更美，这里要有较多的经验和感觉。所以依赖pmd和check style这种我觉得并不能解决根本问题。

个人觉得如果可能，我说的如果可能，是不是需要演化出专门的review人员，有规定的日程，规定的人员（可以深刻理解重构的人），规定的内容，这样做review才能达到真正的效果。

“所以，我们必须要有统一、稳定的编码规范(format, 目录结构等)”这个我觉得和code review没什么关系，不管是不是需要review，规范还是必须的。

47 楼 litian33 2008-08-16  

如果没有10年的编程经验就不要说Review无用
在我们公司所有文档、代码都必需经过Review，无论何种形式都可以
个人感觉还是比较重要的，findbugs、pmd只能发现一些最基本的问题，逻辑问题它们都搞不定

不过Review要有一个大家认同的标准，文档就是标准模板和业界标准，代码就是编程规范，标准统一了才能发现共性的问题，否则Review之后的结果就是PK……哈哈

46 楼 core 2008-08-06  

现在程序员能写代码的 一抓一大把  但是会写代码的很少
代码不会写完能运行就是好的代码
reveiw其实是为了保证质量 和减少以后的不必要或者可以避免的工作
reveiw还是应该的  但是怎么reveiw还是看公司大大的要求

45 楼 younggun 2008-07-26  

xuby 写道

什么pair/review这些方法都不好,好的办法要从中国传统智慧中去寻找.
南北朝时北朝有个皇帝赫连勃勃,要建首都(统万城)的城墙.为了最大程度保证质量,他把团队分为两组,一组施工,一组质监.施工组建完一段墙后,质监组过来做检查,检查办法是用铁枪使劲往城墙上戳,那么结果无非两个,一是把墙戳个坑,或者是墙毫发无损.
对于第一种情况,皇帝的措施是这样的:把施工组的人全部砍头.第二种情况的处理大家可能猜到了,就是把质监组的人杀掉.
采取这种措施的成效非常喜人:近2000年过去了,这个统万城依然屹立不倒.
诸位认为这个质保措施用于软件业,会有什么效果?

你这个方法太极端了，我知道一个比较好的例子是降落伞工厂会让生产工人从自己生产的降落伞中抽出样品来试用。

44 楼 colin2wang 2008-07-25  

我们的QA会来给我们Review的

43 楼 jcs7575 2008-07-23  

fengzhang 写道

我看了大家的讨论，我个人认为大家对于code review的有一些理解是有偏见的。根据我的经验，code review的要求如下：
一、review执行者要求
   1.精通项目组所使用的技术
   2.了解整个系统或者一个模块的业务过程
   3.具有很强的责任感和耐心
二、code review的基本要求
   1.找出不符合项目规范的代码
   2.找出可能在不同的情况下会出现异常的代码
   3.是否是完全符合业务要求
   4.是否对其他的机能造成影响
   以上4点中，后两点是最重要的，但是好多公司和个人往往把1，2点作为重点，也就导致大家认为更本没有必要的想法了。对于业务的检查是没有任何工具能够代替的。

3.是否是完全符合业务要求
4.是否对其他的机能造成影响
请问做这两点需要多少时间和精力，什么样的人能很了解业务呢？项目经理还是业务经理？
不仅要了解业务还得精通技术，这样的人好像不好找啊 呵呵

请赐教

42 楼 jcs7575 2008-07-23  

code review
1.code格式和编码规范用工具检查即可，省时省力我用jtest
2.每本代码必须有资深程序员来review，这个review就涉及重构了，它往往能发现一些代码结构的弊病。

41 楼 hyhongyong 2008-07-23  

项目早期或新人加入时最初的代码要review，之后抽查就可以

40 楼 fengzhang 2008-07-21  

我看了大家的讨论，我个人认为大家对于code review的有一些理解是有偏见的。根据我的经验，code review的要求如下：
一、review执行者要求
   1.精通项目组所使用的技术
   2.了解整个系统或者一个模块的业务过程
   3.具有很强的责任感和耐心
二、code review的基本要求
   1.找出不符合项目规范的代码
   2.找出可能在不同的情况下会出现异常的代码
   3.是否是完全符合业务要求
   4.是否对其他的机能造成影响
   以上4点中，后两点是最重要的，但是好多公司和个人往往把1，2点作为重点，也就导致大家认为更本没有必要的想法了。对于业务的检查是没有任何工具能够代替的。

39 楼 archmaster 2008-07-16  

最好有个check list， 用来保证coding style， class design等的一致性。(开发中自我约束)

然后peer review,由熟悉业务或者senior的人来完成。（开发完成测试前）

还有team review,把比较重要的更新集体检查（学习）（一个礼拜左右）

然后review应该有记录， 有改进。每次有不同的关注， 而且层次日渐提高

可以在building做一些自动化， 比如说用code source anaysis 工具

38 楼 [e-mail] 2008-07-16  

呵呵，Review的人能不能认真做Review是个问题。

37 楼 soartju 2008-07-11  

JavaJason 写道

下面是我和公司一同事讨论得出的一个方案，供大家参考（我们考虑的重点是可行性、实际效果和执行效率）
1．  开发刚开始的阶段，由TL和PM召集大家坐在一起进行几次review（至少3-5次）

其实这一条还有一个含义，减少返工