关于裁剪单元测试过程的一个思考

今天在我参与的一个项目6期启动了，由于公司通过了CMMI3，因此在项目的计划评审时，需要进行开发过程裁剪，当项目经理说到需要裁剪“单元测试”环节时，给出的裁剪理由是：由于项目是按照模块划分的，一个程序员需要完成从后台类到前台的全部开发，因此如果后台类有错误的话，他在调试前台的代码时会很容易发现，因此觉得单元测试没有必要，而且会影响开发效率！

这个项目经理在给出这个解释后，我和公司的另一个EPG成员当时相视一笑，暂时没有发表意见。但这引起了我的思考：

1、这个项目经理是否真正理解了单元测试？

2、即便是按照项目经理描述的那样，一个开发人员实现了一个业务模块的从后台到前台的所有代码，在这种情况下单元测试是否多余，或者说这个项目经理给出的这个理由是否能作为裁剪“单元测试”环节的从分理由？

3、其实我们在开发的这个业务系统是一个大型国企在使用的一个项目管理系统，我们已经开发了6年事情，部署了5个版本，业务可以说非常复杂，那为什么项目经理还会说出，每一个业务模块都是由一个开发人员独自从后台到前台的所有代码？或者说这个系统实际也是这样的吗，个业务模块间的代码彼此独立？

事后我仔细分析了一下，总结出如下几点：

1、这个项目经理没有真正理解单元测试的内涵，其实单元测试是为了提高开发和调试的效率，迅速定位错误而不是增加工作负担。具体是如何提高效率的可以在网上找到很多的资料，这里不再赘述；

2、即便是出现了项目经理描述的那样，用单元测试定位代码BUG也比从页面上调试代码来的快，效率高！真正的程序员都会同意我的看法的！其实会议开完后，这个项目的技术经理就已经表达了这样的看法。

3、为什么一个复杂的业务系统，还会出现一个业务模块由一个开发人员实现从前端到后台的所有代码的情况？这只能说明这个项目的系统分析没有按照面向对象的模式进行分析，而是过早的按照面向过程的方式投入了开发。因此才会出现项目经理描述的问题。对于一个复杂的业务系统采用面向过程的方式实现，该系统的稳定性，易维护性等可想而知了。而如果真正采用了面向对象的方式进行分析的话，一定会找出大量的公共类的，而公共类如果不用单元测试，那么该如何提交给其他业务模块使用呢？

以上是我的一些思考……