发个无聊的贴子，看看大家怎么看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的文章，希望有人能分享一下
[url]http://www.iteye.com/topic/2217[/url]