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