开发完成后总结心得（团队会议稿）

如果要应用到项目中那还是有原则的，比如：A.不能简化代码量的，不用；B.难以上手的，不用；C.不稳定的，不用；D.自己造轮子的（缺乏可持续维护），不用。
基于这几个原则，目前热门技术中，我们不用EXT或者Flex，因为它违反了A和B；不用ibatis，因为违反了A；不用GWT，因为违反了 B；基本不用微软的方案，因为很多MS的方案都违反C；而不自己造轮子，尽量基于标准的Spring/Struts2/Hibernate框架，则是处于人员更迭和维护的考虑，具体可参考J2EE design and development without EJB；我也后悔用Mina，因为缺乏持续性的维护，这方面显然不如netty和grizzly。

 

前阶段开发中存在的问题, 及改进建议（下面提到的问题在任何软件公司都会碰到，所以出现也是很正常，在今天讨论后，建议大家在今后的团队运作中尽量避免）

1、前期需求不明，造成设计时目的不明确，开发时时常会因需求问题而困惑，测试人员也会提出一些需求建议，而由于已经开发完成，所以改动起来比较困难。
 改进办法：需求要完全明确是很难做到，但在局部相对独立功能上应该要尽量明确。如：尽量能明确注册需要哪些信息、每个表单是用什么控件、处于什么范围、列表显示哪些字段、查询需要什么条件有明确的说明，这样可以在后期测试时少掉一半的需求建议或bug。

2、原系统有规范但没有较好的执行，由于团队初成立时，无人严格把控各人的代码规范、文件存放、命名等等都存在着很大的问题，而这造成的结果就是后改代码的时间比前面写代码的时间还要长。
 改进办法：项目组长需要每天都check成员代码，保证每天的代码都是相对规范。

3、设计要慎重，应该要足够的考虑，以及和团队的商议，原系统中有一些数据库表的结构和字段值得商榷，如果前期可以大家讨论一下，也许很多问题可以在后来重构中避免。
 改进办法：没有人能一次就设计出完美的东西，需要及时的沟通，包括与客户的反馈，与其他项目组成员的讨论，这样有助于降低开发时偏离需求的风险。也就是说，在开发之前题，是建立在设计者的想法有客户的确认和开发人员的理解的基础之上。

4、开发时因分工不明确，每个页面可能团队所有的人都有修改，这其实出问题的风险是非常大。事实证明，由于数据库存储过程是专人负责，所以不必要的 Bug相对较少的，而UI层的不少问题其实都是后者根本不清楚前者的代码意途所致（必要的注释是起码的习惯，松耦合的code是更好的代码风格）。
 改进办法：数据层、逻辑层、UI层，以及UI的各个功能分工，都需要责任到人。

5、代码中重复代码较多，维护时时常会改了一处Bug，却在另一处出现同样的问题，这显然是重复带来的灾难。
 改进办法：开发时，只要是重复代码，就需要考虑是否可以提炼成为函数，并考虑存放到合适的类中（也包括页面html的重复），严禁简单的Ctrl+C到Ctrl+V，这种避免重复代码的做法看似相对麻烦，其实是可以大大减少维护风险。

6、计划不能按期完成，大致三种原因，1、计划不合理；2、人员没有抓紧；3、因其它计划外的原因造成延误
 改进办法：制订计划项目组长需与相关成员讨论以决定计划完成日期，制订时间需要科学合理，如果明确后，相关成员需要尽量按时完成，若有特殊原因，比如技术难题，计划外的事情耽误等等，需要给出理由。再由组长和成员共同商议解决时间，以保证全局的进度不受影响。

7、早期没有存储过程测试，单元测试，页面测试因需求不明，造成测试人员既是测试者又是需求提出和建议者。
 改进办法：需求制订过程需要测试人员全面参与，达到了解足够充分。测试时针对需求做测试用例，以需求为标准，判断开发是否完成或有否错误。

8、前期页面比较混乱，页面布局、样式比较混乱，到处都有如居中、加粗等html语句、列表显示有5种样式等等，造成后期重构非常麻烦。
 改 进办法：美工应该在需求制订完成后就介入，进行页面设计，然后.net的aspx页面需要有专人处理，所有的样式必须全部用css统一完成，表单验证、页 面跳转需要在开发前完成（甚至最好可以经过测试），这需要界面设计人员（可能是美工也可能是架构师或界面专人）对需求充分了解。

9、项目计划和管理主要以Email和口头传达，过后无法跟踪，造成时间表不明确，人员工作效率不够高，有时很紧张，有时很轻松。
 改进办法：需有项目管理工具，比如VS 2005 Team System或其它项目管理系统。每个人的工作任务需在其中体现，计划安排和调整，相关负责人，延误备注都需要记录。让开发人员保持一个长期的、恒定的开发速度。

总之，由于早期开发时团队人员不整、需求不明、规范实施不利、计划有误等等原因，造成系统开发出现些了问题，但之后有了一定的时间，所以重构已经取 得了不少成效，但所谓磨刀不误砍柴工，前期的准备如果充分一些，对后期的维护就会好很多很多。由于时间关系，前期不可能做非常详细的设计，事实上，即使做 了详细设计也可能因需求的变更而效用不大，所以更多的是需要大家写出可维护性、可扩展性和可复用性较好的代码，以便更好的适应变化。

最后，以软件大师Robert C.Martin的名言与大家共勉

个体和交互               胜过     过程和工具
可以工作的软件       胜过    面面俱到的文档
客户合作                   胜过    合同谈判
响应变化                   胜过    遵循计划

虽然右项也具有价值，但我们认为左项具有更大的价值。