我对现在正在作的项目的一起疑问和建议

    一、开发和部署方式是否需要改变
        二期的开发和部署是各个webmoudle和ejbmoudle分别打包部署，这样使的各个不同功能模块的应用比较独立，公用的jar包引入，不同的应用单独开发和打包，使的后开发模块对以前开发部分影响最小，而且利于统一管理和扩展维护；建议三期也采用这种方式，把我们现有的代码进行统一规划和分解，将工程也分解为独立单一的不同moudle。
    二、项目管理以及开发方法
        极限编程的12个最佳实践有些对我们使适用的，如 小版本、简单设计、测试、重构、编码标准和持续集成，采用这几个开发方法，会提高我们的代码质量，减少错误，加快版本发布的时间，采用迭代开发使我们可以更快的看到的开发目标，采用持续集成和日构建可以使我们的版本发布效率会更高。
        测试：我们采用分层开发，只有测试过的代码才可以放心使用，否则再集成调试的时候会增加很多除虫的困难，时间再紧也应该写测试代码；
        重构：一旦发现重复的代码，就重构，这样不但可以提供代码的质量而且可以可以提高开发效率，小范围的重构是允许的，但软件架构的重构需要慎重，但我们dao的使用和处理 是否需要重构 ，还得讨论决定；
        编码标准：编码得严格按照编码规范来进行，但规范是文档，是否认真执行还得靠个人，因为建议采用checkstyle强制控制代码的格式和命名；
        持续集成：采用日构建和自动集成工具以及自动化测试工具可以减少人工的工作量，可以尽早的发现问题和解决问题 ，建议采用 CruiseControl和winrunner或者seleium   ，这俩个工具我也没用过，但引入是有必要的；
    三、是否应该定义一致的开发规范以及约束
        对系统中的配置文件应该统一管理，建议放到统一的位置,禁止再代码里写死配置文件属性，将jndi、soapUrl等等需要配置的文件放到一个统一的目录，方便修改和管理；
        建议统一使用eclipse作为开发工具，建议调试使用断点跟踪方式，建议按照javadoc注释代码，建议代码由subversion统一管理；
      
    四、是否使用web2.0部分功能
        web2.0可以给用户更好的体验，我们是否再三期中部分采用ajax，具体不再阐述；
    五、文档是否同步更新
        尽管时间很紧，但建议还是作文档的同步更新工作，这样可以再项目的后期维护和扩展提供尽可能多的参考资料；

>>    近一天在看我们三期的代码，在看的过程中产生了几个疑问，拿出来和各位讨论，以下纯属个人意见：
>>
>>    一、为什么不用hibernate3？
>>        我们既然用了hibernate，为什么用2而不用3呢？3不仅仅是包名的变化，而且在很多地方比2都作了很大的提高何更新！现在hibernate的最新版本是3.3，版本3已经被大量的在使用，我们使用是没有任何问题的！
>
>      这个观点我赞同，我也认为既然用hibernate，还是用3比2要好些。在性能，稳定性方面应该有提升。虽然我没有切实的数据证明这一点。
>>
>>    二、为什么不用Spring？
>>        spring作为ejb的替代品现在是轻量级开发框架的首选，而且spring和hibernate是黄金搭档，这俩个框架的结合节省了大量的代码，可大大提高代码的质量和开发速度，提供了很多好用的模版和复用代码！
>>尽管对远程调用和分布式集群支持的不是很好，但我们在dao层和webapp层和代理层之间完全可以部分使用spring，如现在的dao工厂调用模式用spring的基于工厂的ioc机制完全可以实现，而且通过更改配置文件绝对比改接口类优雅和舒服的多！我们也可以用spring包装ejb完成代理层的实现，而且spring和struts的结合，对整个项目的业务层串联和粘合绝对要好的多，至于其他好用的功能再此就不列举了！
>
>      现在这个框架是领导最初定的。当然Spring对于开发组成员来讲，具有一定的学习曲线。如果项目不紧的话，是一个不错的选择。或许使用spring框架可以有磨刀不误砍柴功的效果。我对Spring不太熟，没有发言权。
>>
>>    三、事务如何控制？
>>        我们选用ejb的目的我想还是看中它可声明性的事务配置，但我们的ejb实现却没有一个抛出EJBException，这样可以实现事务控制么？我对此有很大的疑问！
>
>       事务的控制我也有疑问。我认为EJB事务控制通过声明性配置是必须的，之后还必须有两种之一要做才能起到控制事务的作用。其一,通过声明和抛出EJBException;其二,通过context.setRollBackOnly()方法显式回滚。
>       另外，这种方式能不能控制包括hibernate在内的事务我还不太清楚。
>>
>>    四、Dao的工厂调用方式是否合适？
>>        我们dao实现的调用用的的DAOFactoyry创建的DAO接口，接口的实现类通过类型反射得到它的实现，这种方式在性能、效率上不知有没有测试过，是否可以满足河北增值平台如此规模项目的设计要求，如果用spring则完全可以解决这个问题，而且spring对反射的处理效率要高的多，而且修改配置文件远比要修改DAOHelper接口增加新的类要好的多！
>
>        我认为通过类型反射得到实现类和通过spring解决问题在性能和效率上最好有确切的数据来证明可行不可行。
>>
>>    五、Struts-config.xml为何只有一个？
>>        目前我们各个webapp的struts-config.xml只有一个，大家都在一个文件里累加，我的疑问是这样不是不可以，但struts支持配置文件拆分，拆成多个不但可以利于维护和扩展，而且对团对开发也有帮助!
>
>     我们在北京项目曾经使用过一段struts-config.xml拆分的方式，有它方便的地方，但是也存在一些不稳定的要素。我们在iplanet部署时，经常会出现冲突或是找不到跳转的情况。我不知道是不是配置不对。
>>
>>    六、jsp和部分代码为何没有作到重用？
>>       我们一只倡导代码的复用和重用，就是遇到相同的重复的代码要把它重新封装和提取，但在我们的jsp和代理类里有太多的重复代码，这样不利于以后代码的扩展和维护，把相同的功能的代码提取到一个文件或者一个方法，可以统一修改和维护！
>      jsp部分的代码重用复用我没有看，但是对于业务逻辑和dao部分的重用复用我有疑问。
>>
>>    七、为什么没有单元测试代码？
>>       我们可能作了单元测试也可能没有作，但测试代码应该是有的，对自己写的类一定要先用junit或testcase运行通过才可放心使用，TDD似乎我们用的不好？
>
>      我同意吴的建议。
>
>>    八、注释何代码编写为什么没有统一规范？
>>       我们在二期的维护工作中吃够了文档不全和代码注释不规范不及时的苦头，希望在三期中这些问题不要在出现了，尽管我们时间很紧，但我们也应该把有限的时间投入到无限得注释代码中去，如果作不到文档最新，但一定要保证注释最全！
>