发个无聊的贴子，看看大家怎么看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
52 楼 RCFans 2008-09-01 CMMI 3级就会制定标准的Code Review范本，照着上面的做就是了，感觉还很有用的 53 楼 mindxw 2008-09-02 kimmking 写道传统的公司中，pair不可想象，
试问：领导者如何会乐意见到每时每刻都有一个人在“闲”着！
理想的pair还是很不错的选择,问题是pair之间的互动并不像某些人想象中的那样,这种情况下,你怎么办? 54 楼 mindxw 2008-09-02 younggun 写道xuby 写道什么pair/review这些方法都不好,好的办法要从中国传统智慧中去寻找.
南北朝时北朝有个皇帝赫连勃勃,要建首都(统万城)的城墙.为了最大程度保证质量,他把团队分为两组,一组施工,一组质监.施工组建完一段墙后,质监组过来做检查,检查办法是用铁枪使劲往城墙上戳,那么结果无非两个,一是把墙戳个坑,或者是墙毫发无损.
对于第一种情况,皇帝的措施是这样的:把施工组的人全部砍头.第二种情况的处理大家可能猜到了,就是把质监组的人杀掉.
采取这种措施的成效非常喜人:近2000年过去了,这个统万城依然屹立不倒.
诸位认为这个质保措施用于软件业,会有什么效果?
你这个方法太极端了，我知道一个比较好的例子是降落伞工厂会让生产工人从自己生产的降落伞中抽出样品来试用。
两位都很极端,也很幽默.
哈哈!!! 55 楼 raylin 2008-09-05 andyhu1007 写道code review: 费时，费力，交流麻烦。推荐pair。
code review 还是有必要的。不是所有人都喜欢Pair的。这要看组织文化了。 56 楼 raylin 2008-09-05 关键是Review的 Scope 很重要。大家不妨在这个话题上面探讨下经验。有那些东西值得Review，有哪些东西是不值得去花这个时间去Review的。
公司性质不同也许Review的侧重点也不同。比如外包公司可能文档之类的Review就要求的比非外包公司严格。
