code review

3个月前，经过了大约2个星期的，很耗心力的设计，然后4，5天的实现，完成了一个模块的第一版，里面的算法异常的复杂，当时的感觉是如果这个问题再难一些，我可能就不能在这个方向上搞定了。

测试结果跑出来ok之后，长吁一口气，轻松的靠在椅子上，这时候突然脑袋里闪出一个问题：

我这刚刚写好的几千行代码，可以被code review么？

答案是不能被轻松的完成，一个合格的review，需要针对问题，设计，代码实现（其实也就是当前这个程序员所做的工作）都要看一下，而不是单纯的过一遍代码。

那种看看那里是不是会忘记释放内存，那里是不是多一个标点符号这样的，对于解决问题本身没有实质性帮助的方式。

code review的性价比

“code review是有好处的，1，xxxx，2，xxxx”我觉得这种不谈性价比，只谈好处（或者坏处）的讨论是不完全的，也不足以做为项目是否要启用code review的充分条件。

之前beyond3d上面也发起过一个讨论：http://beyond3d.com/showthread.php?t=63079

最后结论就是，code review也是一分价钱一分货，很多项目觉得性价比太低，最后决定不做。

我经过的所有项目的做法（其实也是我认识的开发者里面除了google都这么干的）：要过milestone才做一些有限的code review，防止做过激的改变，犯低级错，这样的review也只能做到这样的事情，项目组其实也只是需要这么多。

但是如果项目组开始需要超极高的稳定性，非常高水准的设计，良好的代码结构等，那么在code review上，以及开发者的职责分配上就要做更多的投入，在google工作的同学说他们就属于这种。

进度上么，投入大的当然要慢了。

上面算是两个极端，现实中也会有reviewer在那里听实现者说一遍，实现者自己也会发现问题的情况

更进一步的code review？

如果项目组就是要追求更好的设计，代码质量，愿意付出进度的代价，我们再进一步的code review，其中会遭遇到的最大挑战是什么呢？

个人的看法就是个人在项目中的职责要发生改变，一块东西就是要变成由多个实现者来负责的，这个东西是你们来共同开发的东西，而且现在这样，在项目的未来也是这样。

否则一旦头脑里有，这一块我只是来review的，这样的想法，其把这一块做到极致的内驱力就会大幅度下降，工作这么多年下来，感觉在一个大型项目里，有很多模块，真正做好真的是不容易，需要在相当大的广度深度以及足够长的未来时间跨度上面去求最优解，没有足够的内驱力，review者（在和实现者同等水准的情况下）便无法探索出真正优秀的最优解，就会和实现者偏向同一个解决方案，然后变成vc compiler这样的，辅助型同事，而这又成了很大的人力资源浪费。