发个无聊的贴子，看看大家怎么看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

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

基本上是这样！check style 可以通过工具实现。

pair是不错的实践。

pair会不会太不自由了？

为什么你需要自由？

两种意义上的自由
1是编程的自由 在有一个能跑的结构之前 我不喜欢别人来打扰我的思路
2是个人自由 也许我写了一个头文件之后想去倒杯水 想看看今天的比赛直播 或者想打个电话 可如果有个同事就在身边等着我。。。

2是不需要的
1在绝大多数时候也是不需要的，真的需要的时候你可以暂时不pair嘛

等等 为什么2是不需要的？难不成老板要说，我付给你8小时工资，你就得干8小时的活？

想休息可以休息，但是要清楚每段时间是在做什么。跟同伴说一声“我现在要休息半小时”有助于更好的管理时间。