我在2004年4月份来到中软融鑫，至今已经8个月了，期间先后负责和参与了多个项目，取得一定的成绩，也发现了诸多不足。在此，我想对项目开发过程的经验进行回顾和总结，同时对自己新的一年的职业发展提出规划。

总结这一年的项目开发经验，我认为软件开发最突出的特点是人的要素起着决定性的作用。其中用户需求的易变性和开发者素质的不平衡是影响软件质量的两大要素。而软件开发的目标应该是以最小的开发成本满足用户不断变化的需求。传统的软件工程通常是通过大量的文档、繁琐的审核流程来控制上述两个要素的影响，需要花费更多的成本，却收效甚微。相对于以往重量级的、以文档为中心的软件开发方法，目前业界已经提出了一些轻量级的、以代码为中心的软件开发方法，比如极限编程等，来解决上述的问题。在这里，我不想描述哪个现有的软件工程方法，而是将我这一年的软件开发经验总结成若干条。虽然这些经验可能不是很系统，但我想它们反映了轻量级软件工程方法的思想，对于在实际的软件开发如何提高开发效率，减少不必要的开发量，从而能更快的适应用户不断变化的需求应该是非常有益的。

（1） 提交给用户的软件产品主要部分是程序代码，所以代码自然是满足用户的最新需求。而软件文档通常做不到随着用户需求变化而更新，比如与代码相脱离的详细设计文档到了项目末期，和代码根本对应不上。解决方法是不要写无法与用户最新需求同步更新或更新成本很高的文档，这些文档除了增加开发成本，没有什么用处。比如需求等更新成本较小的文档，可采用人工方法保证同步更新；而详细设计文档或部分概要设计文档（比如数据库设计、接口定义等）更新成本很高，此类文档应写在代码中，与代码同步更新，然后可以采用像javadoc的方式导出为独立的文档。

（2） 在项目组中，软件开发人员的素质可能是参差不齐的，这对软件的质量会有很大影响。我们应努力使整个软件产品的质量等同项目组中最高的开发水平（通常是主设计师的开发水平），而不是最低的开发水平。如果要求项目组每个人的开发水平都很高，会大大增加开发成本。要减小产品质量对普通编码人员水平的依赖，有以下的解决方法：

l 设计师提交给开发人员的工作成果不应只是文档，还应该有能够实际运行的框架代码，这些代码规定了系统的底层平台、体系架构、各层的接口、公用组件等信息，普通编码人员只需根据业务需求实现相应的接口即可。

l 只提供框架代码，还不能完全保证编码质量。应该由设计师持续对系统的所有代码进行检查，随时提出改进意见，督促编码人员进行修改。

（3） 采用成熟、合适的应用框架作为开发的平台，可以大大降低开发量。举例来说，若采用struct+spring+hibernate框架进行开发，政务信息系统就可以不编写像dao层、事务控制、数据库连接管理、异常控制等大量代码，至少可以降低代码量30%以上。

（4） 用户需求可能会不断地改变，但是试图控制用户需求的变化，在实践中通常行不通。最好是采用迭代和重构方法适应用户需求的变化。迭代和重构体现的是持续设计的思想，采用最简单的设计满足用户目前的需求，在用户需求变化时，重新进行设计，对代码进行重构。一开始就根据自己的想象进行复杂的设计，以为能满足用户所有的需求变化，这是不现实的，而且会增加开发的成本。

（5） 软件开发中的人员分工应按照技术架构而不是按功能模块。按功能模块分工，要求普通开发人员熟悉比如html、javascript、jsp、struct、spring、hibernate等从前台到后台的所有技术。要求每个人成为全面的技术专家是不现实的，应该按照系统架构的层次（比如分为表示层、控制层、业务层、持久层、数据库）进行分工，象流水线一样，每个人组装一部分组件，然后集成成为可运行的系统。同时还需要加强单元测试和持续集成来减小集成的风险。此外，这种分工方式也有利于设计师控制系统架构中各层之间的接口符合设计要求。注：从目前的软件开发经验来看，还是功能模块来划分比较好，首先不能要求每个开发人员都成为业务专家；其次系统架构的层次之间耦合性比功能模块的耦合性高，不利于并行开发和责任划分；2006-5-8

（6） 应善于采用开发工具降低开发的工作量，比如采用ant+xdoclet可以大大降低strutct-config.xml文件的维护工作量。

在总结软件开发经验时，提到了按照技术架构来进行人员分工，这实际体现了专人专职的思想。我想从这点出发，谈谈对自己新的一年个人发展的一些想法。对于技术人员来说，广泛的涉猎是必要的，但必须能够专注于某一技术领域，才能最大体现自己的价值。在新的一年里，我想继续专注于J2ee体系架构和数据库设计方面，希望成为这方面的技术专家。对于在项目开发的工作定位，我觉得自己适合作为开发的组织者和主要设计师。