常飘在天上的代码评审Code Review

细究成因可能是来源于两个方面：

一是时间压力太大。

软件开发里可以安全打折扣的地方其实不多，文档不写很容易被看出来，代码不写程序就动都不动了。

没办法下，很多时候就只好拿Code Review开刀。

毕竟Code Review里少看两眼，多看两眼，用多少心思看，其实是个良心账，外人看不出来的。

同时，Code Review本身也确实是个费时间的活。

另一种成因是看不见成效。

如果把CodeReview只等价为坐在一起看代码，那么很可能Code Review中确实无法取得实效，这样做来做去，大家也就疲了，觉得这是个浪费时间的事情。

这点和上一点有点关联，一旦时间紧，就要求编码快；编码快，对具体某一个人而言，不理解的部分就变多；再加上无法预留充足的Code Review时间。

那么，除了作者外，参加Review的人对看的代码很可能是不懂的。不懂的话，也就只能糊弄，随便找点问题搪塞下。

从这个角度看，追求高生产率应该是错误的，生产率本身应该是个区间：低于某一值的是磨洋工，高于某一值的则是质量换速度。

毕竟人力有时穷尽。

单就项目时间压力这一点而言，通常并不能在项目自身范围内解决，牵涉的也比较多，暂且不论。

看不见成效这点却可以想点办法来改善。

改善的一个主要手段是要明确“不看什么”和“看什么”。

需要注意的是，大多时候“定义不看的”很可能比“定义需要看的”还关键。

当然这里的前提是“时间压力下，尽可能获取成果。”如果一个项目有的是时间，那就不妨把每行都找几个人仔细看看。

我个人感觉，CodeReview中，第一个不要干的事是“和测试抢饭碗。”

用CodeReview来检测基本功能的实现是否正确这一行为本身不能讲完全错误，但至少是低效的。

从产品角度看，CodeReview应该和其它手段形成一定互补，而非是尽可能的重叠。

第二个不要干的事情是和“和静态测试抢饭碗”。

但凡可以依赖静态测试得出的结论的事情，在CodeReview中应该被忽略，比如：函数复杂度等。

这样CodeReview中应该干的事就变的清楚些了。

测试很难覆盖的区域，如：多线程同步，极端条件的处理等。

逻辑是否清晰，如：基本结构和设计的偏差，全局变量的使用是否合适等。

静态测试无法覆盖的编码风格。编码规则中东西尽可能自动分析，但总有些东西无法自动检查，比如异常使用的是否合适等。

这类东西也只能在CodeReview中覆盖了。

在CodeReview中，我倾向与做减法而不是加法，这样想的一个关键前提就是，项目的时间似乎总是不够，

这时候就只能让CodeReview，静态测试，单元测试这些职能进行互补，而不能让他们尽可能重叠。

服务器租用/服务器托管中国五强！虚拟主机域名注册顶级提供商！15年品质保障！--亿恩科技[ENKJ.COM]