细究成因可能是来源于两个方面：
一是时间压力太大。
软件开发里可以安全打折扣的地方其实不多，文档不写很容易被看出来，代码不写程序就动都不动了。
没办法下，很多时候就只好拿Code Review开刀。
毕竟Code Review里少看两眼，多看两眼，用多少心思看，其实是个良心账，外人看不出来的。
同时，Code Review本身也确实是个费时间的活。
另一种成因是看不见成效。
如果把CodeReview只等价为坐在一起看代码，那么很可能Code Review中确实无法取得实效，这样做来做去，大家也就疲了，觉得这是个浪费时间的事情。
这点和上一点有点关联，一旦时间紧，就要求编码快；编码快，对具体某一个人而言，不理解的部分就变多；再加上无法预留充足的Code Review时间。
那么，除了作者外，参加Review的人对看的代码很可能是不懂的。不懂的话，也就只能糊弄，随便找点问题搪塞下。
从这个角度看，追求高生产率应该是错误的，生产率本身应该是个区间：低于某一值的是磨洋工，高于某一值的则是质量换速度。
毕竟人力有时穷尽。
单就项目时间压力这一点而言，通常并不能在项目自身范围内解决，牵涉的也比较多，暂且不论。
看不见成效这点却可以想点办法来改善。
改善的一个主要手段是要明确“不看什么”和“看什么”。
需要注意的是，大多时候“定义不看的”很可能比“定义需要看的”还关键。
当然这里的前提是“时间压力下，尽可能获取成果。”如果一个项目有的是时间，那就不妨把每行都找几个人仔细看看。
我个人感觉，CodeReview中，***个不要干的事是“和测试抢饭碗。”
用CodeReview来检测基本功能的实现是否正确这一行为本身不能讲完全错误，但至少是低效的。
从产品角度看，CodeReview应该和其它手段形成一定互补，而非是尽可能的重叠。
第二个不要干的事情是和“和静态测试抢饭碗”。
但凡可以依赖静态测试得出的结论的事情，在CodeReview中应该被忽略，比如：函数复杂度等。
这样CodeReview中应该干的事就变的清楚些了。
测试很难覆盖的区域，如：多线程同步，极端条件的处理等。
逻辑是否清晰，如：基本结构和设计的偏差，全局变量的使用是否合适等。
静态测试无法覆盖的编码风格。编码规则中东西尽可能自动分析，但总有些东西无法自动检查，比如异常使用的是否合适等。
这类东西也只能在CodeReview中覆盖了。
在CodeReview中，我倾向与做减法而不是加法，这样想的一个关键前提就是，项目的时间似乎总是不够，
这时候就只能让CodeReview，静态测试，单元测试这些职能进行互补，而不能让他们尽可能重叠。
原文链接：http://www.cnblogs.com/daoshi/archive/2012/09/03/2668175.html
【编辑推荐】
