大凡在日企里面做过leader的项目管理人员都比较喜欢review吧。今天早上收到课长的email，提到：“质量是做出来的，而不是检测出来的；高质量不等于高成本，高质量是预防出来
的*”……“测试是验证，而不是
保证质量。高质量不一定要多加人，延长交货期。
提高质量，要有良好的设计，严格的执行（过程管理/配置管理，含review）”。
结合平时的经验，所谓过程管理和配置管理都是比较务虚的东西，反而是review，每每被提起，仿佛是解决bug的灵丹妙药。
加*的那句话本来是来自一家传统快餐企业的企业箴言，这里被课长转过来以共勉。但是传统企业和软件开发究竟有很多不同，这样简单的类比（似乎很多人都喜欢把软件开发和传统企业类比起来，并取了一个比较好听的名字，叫做“软件工程”），我并不苟同。下面是一些简单的分析
其一，软件开发的核心在于人，在于一个个的单独程序员，不管什么过程控制，人却恰恰是不可控的（有时间我想写写过程控制和人的控制方面的blog)，也就是你必须尊重每一个开发者，而不是从生产机器的角度去看待他们，这从根本上说明了传统企业与软件开发的不同。所以就应该以不同的眼光看待测试，以及所有的生产过程。
其二，在传统企业里面，测试是为了检验，但是作为一线的开发人员，我认为在软件开发中，测试除了检验代码和逻辑的正确性，更多的是一个开发者的思考过程（这一点在UT过程中尤其重要）。每一次的测试迭代，都有可能产生新的需求和更好的解决方案，但是review能有这样的功效吗？
其三，软件开发的每个模块都有其自身的特性（起码现阶段的开发就是如此），不同的开发者可能实现的逻辑和方法并不相同，review的人很难在短时间去透彻的了解开发者的观点和方法，也就很难发现真正意义上，深层次的bug，最多就是在语法逻辑上浅层次的去发现一些问题。
综上所述，我认为review并不是减少bug的灵丹妙药，而且随着xp等新的开发方式的产生，review所能起的作用会越来越少，未来的开发到底会演变成什么样子，我们拭目以待。
本文地址：http://com.8s8s.com/it/it33739.htm