常飘在天上的代码评审

虽然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，静态测试，单元测试这些职能进行互补，而不能让他们尽可能重叠。

 

--------------------------------------------------------------

 

 

 

理想流 + 软件 = 《完美软件开发：方法与逻辑》
理想流 + 人生 = ??
理想流 + 管理 = ??
理想流 = 以概念和逻辑推演本质，追求真理。