MPPT项目是为巴西电信开发的基于软交换技术的J2EE项目，在这个项目开发中，使用的主要技术有业务工作流，EJB组件。和所有的使用了EJB技术的J2EE项目一样，这个项目前期需求分析，设计，编码都非常顺利和迅速，进入测试阶段以后，使用EJB技术开发J2EE项目难以测试的缺陷暴露的体无完肤，还在通过查看日志文件跟踪测试业务功能点，真是晕死！最主要的是这个项目需要ENIP平台环境，测试初期，我搭建ENIP平台就费了很大的劲，另外还有配置软交换环境和信令数据，多亏项目组的兄弟帮忙搭建。做到后期，发觉有个功能点的测试用例我无法测试，这个功能点是编码阶段我接过来的，需求分析和设计我都没有参与，从编码回朔到设计在回朔到需求分析文档，才发觉需求规格说明书中说明这个业务点是需要编写存储过程实现，但是这个业务点的确通过一条SQL语句就可以搞定啊，可能是写到设计说明书的时候，那个兄弟就不按需求来了，真是晕死！！没有办法，改吧。先改代码，为了减少导致的修改范围，只修改DAO类，把个DAO类修改的不伦不类，OK，再写存储过程吧，这个时候才发觉，存储过程说明书中没有这个存储过程，怎么办？存储过程说明书已经基线了，只好向配置管理的MM申请开放权限吧。改完代码和存储过程说明书，然后打包上传，加载激活业务。测试通过，OK，更新版本，搞定！
说到这里，今天碰到一个笑话，一位项目组的兄弟评审另一位兄弟的代码时，发现有一个地方的注释有问题，于是就提了一个评审建议：注释有问题。可是后面这个兄弟拒绝了这条建议，拒绝原因是：不知道有什么注释问题。如此强的拒绝原因把整个项目组的兄弟都笑弯了腰。
