代码审查是一个好东西，从理论上说，它可以即时（就在代码编写的当天下午）的review代码，以最小的成本发现潜在的隐患，把问题消灭在萌芽状态；同时由于还有至少另外一个人看懂过这部分代码，项目就不会严重依赖于某个个人。但是，在管理中非常忌讳的是一听到先进的东西，就赶紧照搬到企业中，也不管各种配套措施和前提条件是否具备。如同中国的教育产业化。当然也忌讳固步自封，不思进取。

　　那么，代码审查的前提条件是什么呢？

　　第一个条件就是要有统一的编码规范，如果一个软件公司这一点都没有做到，那就是彻底的土匪军，代码审查这种正规军的做法就不要考虑了，先把编码规范建立并培训普及起来。

　　第二个条件就是开发人员要比较多，多到至少一个模块有两个人在做；或者至少每一个模块除了开发者之外，还有一个熟悉理解该模块的人。为什么需要这样，其实很简单，代码审查的目的是要能看懂并真正理解代码和潜在的设计思路，试想如果都看不懂又如何发现问题和以后可能的顶替呢？在一个项目，每个人负责N多个模块，各个模块之间功能、设计、算法差别又很大，如果强制规定必须进行代码审查，那岂不是要求大家都在学习别的模块，并努力发现不符合编码规范（例如没有必要的空行等）的小错误，以应付要求。另外，在这种项目中，每个人的任务都是满满的，谁也不会有兴致和时间去学习另一个陌生的模块。

　　那么，在不具备第二个条件的软件企业/项目中，是否就无法进行代码审查了呢？也不尽然。在我同事所带领的一个项目中，就采用了另一种方式来进行代码审查，也取得了预想的效果（虽然不是正规意义上代码审查的效果）。在这个项目中，除了项目经理外，其他几个开发工程师都是刚毕业的新员工，所开发的产品已经发展很多个版本，产品规模巨大，模块众多，项目开发人员又不多。如果按照正规意义上的代码审查，结果是预想而知的。那么，该项目经理就采取了另一种形式，就是定期把几个开发工程师召集在一起，来阅读和分析某个开发工程师最近完成的一个小功能，通过对该功能的分析和代码的阅读，项目经理给出点评，变相起到了一种设计培训和代码规范培训的作用。

　　所以代码审查可以分为两种方式、对应两种目的。

　　第一种方式是任何软件项目都可以、且应该做的，就是在开发之前或者前期，由有经验者和开发工程师一起来阅读一段代码，有经验者评点这段代码，指出设计上和代码实现上好的或者可以改进的地方，开发工程师可以提出一些疑问，共同讨论；这样主要起到培训和代码规范的目的。这种审查方式不用经常进行，开发初期、尤其是部分开发工程师水平还有待提高时，做3-5次就可以了。投入不大，效果明显。

　　第二种方式是主要发现代码中存在的隐患和问题为主，一般在开发阶段，每天下午四五点之后，由开发工程师之间，交换检查当天编写完成的代码，检查完毕后，再提交到代码库中。这种方式投入成本高、且必须每个模块都至少有两个人比较熟悉，否则就发现不了存在的隐患和逻辑错误，只能做代码规范层面的检查。但如果一个项目团队拥有了足够的资源保证，就完全可以做到每天进行这样的审查；这种审查可以在第一时间review编写（增删改）的代码，对于提高代码质量，发现并解决潜在的问题有极大的好处，可以大大降低在后期测试或者用户使用中发现缺陷的概率，减少维护的开销，提高产品的品质；从整体上看反而会减少工作量，缩短开发周期。