2011.12-项目敏捷改进意见
1. 升级源码版本控制
存在问题： 目前我们项目开发中采用源码版本管理工具为cvs，cvs作为第一代源码版本控制器，无论是从易用性，还是学习上手都是比较简单的。但作为源码版本控制服务的始祖，cvs存在着一些缺点：
1) 每个文件维护一个版本，当想检出项目整体某个版本，很有可能就遗漏了最新更新的文件；
2) 对二进制文件(image/bin/jar/zip/rar等)支持的版本控制能力较差，容易造成数据的混乱；
3) 当多人同时编辑一段源码时候，源码内容发生冲突，cvs在源码内标记冲突位置不都明显。
4) 文件版本状态不明显标记，如更改过的文件在IDE项目工作区中不明显，eclipse只是简单的显示一个>；
5) 文件目录操作支持差，操作繁琐。如删除、重命名文件，一旦执行这些操作版本数据丢失。
虽然这些问题再我们项目开发中可能遇不到，当其潜在的问题一旦出现可能就会对项目开发造成阻碍。
解决方案: 对新项目采用第二代源码版本管理工具SVN，或直接采用Git。考虑到我们的操作习惯和团队成员数量，比较适合选择SVN作为我们的源码版本控制服务，如后期我们所承接项目规模更大和团队成员增多可采用Git版本管理工具。
方案优势:
1) 图标覆盖功能(TortoiseSVN、subclipse)，方便的看出当前文件的版本控制状态。
2) 提交时所有文件版本号统一增1(即使有的文件一点都没有变)，且文件目录也维护版本号。较之cvs每个文件一个版本，好记且提取历史版本方便。
3) 便捷的文件操作功能，如TortoiseSVN 和 eclipse插件subclipse实现与Window和eclipse ide无缝链接,目录操作功能对管理维护版本库的文件操作明显简单。
4) 对二进制文件支持较好，对所有托管文件实行客户端和服务器端均采用差异化储存。
5) SVN实现对目录进行权限分配 ，精确到目录级别的控制。
6) 提交动作的原子性，即有一个文件提交不成功，整个提交动作就失败，变化不会存储到版本库中，有利于源码版本的统一。
2. 引入UI组件
存在问题: 目前根据所接触不多的几个项目，我们项目组所开发项目均为基础数据的整理分析工作，项目UI主要负责展示数据，与用户交互程度一般。其原因可能因为我们没有专业的美工和前端开发人员。作为偏向后端开发人员的我们，负责一个模块往往要从页面都后台代码全包，对后台数据处理我们借助强大的java语言和统一的jvm运行平台能够很好的完成开发任务。而我们在数据展示层的开发是耗时巨大。究其原因，一为个人均为手动从零使用html+css+javascript布局UI结构，在各个模块对UI组件重用性差、一致性差（不同模块的同一功能的组件可能由多人设计，不但有工作重复，还有用户体验不一致的缺陷）。二为对浏览器的差异性的兼容耗费较多工作量。如我们的客户要支持ie6，就存在很多css和javascript的兼容性代码编写和测试。
解决方案: 在新项目中采用RIA框架 jQuery UI 或extjs
方案优势:
1) 两UI框架均为基于javascript的开源框架，学习成本低。
2) 两者兼容性好，且对ie6+的支持较好，且都有丰富的组件。
3) Extjs功能强大，且UI较为华丽，交互性明显强于jQuery。当布局较为复杂的UI界面时候，extjs能明显减轻我们的前端页面编码工作量，且借助chrome自带的浏览器也能够对布局js进行更为轻松的测试和调试。
4) jQuery UI为基于jQuery的轻量级的UI组件框架，可以根据项目的需要，进行深度的功能裁剪。网上有众多jQuery拓展插件供我们选择，自己开发一个基于jQuery拓展插件也较为容易。距我所知，不少嫌弃extjs笨重的公司都居于jquery封装出自己的UI界面，甚至做的可以在易用性和功能上媲美extjs，而效率更高。jQuery UI唯一缺点就是不支持非html5浏览器的UI圆角化，不过这个缺点在我们的内网专用系统中影响不大。
3. 基础框架模块化和深度使用
存在问题：目前我们开发基础框架都是居于SSH三大框架的二次封装，虽然封装了较为常见的开发功能，但从易用性上来看，还不够便捷。鉴于SSH三大框架的功能的众多，可能在封装过程中，会忽略框架内置的一些功能，而自己重复造轮子，但从性能和易用性来看却比不上框架内置功能，且初次入手需要学习使用。在进行某些封装的时候，可能为了编码方便，而忽略了java某些组件的规范，导致基于使用java ee标准技术无法直接调用(如el无法调用无getter的bean属性)。如对事务的管理粒度过小或界限不当，如无法使用hibernate的延迟加载，因为session在service层就已经关闭。
即使对性能要求不很严格的项目中，始终在源码中对数据库的存取大量使用原生sql语句或hql语句来进行操作。虽然这是出于程序员的直觉，但在编码阶段我们要花费心思来构造语句，很多情况下都是纯手写，而无法得到ide的代码提示功能的协助。而在项目后期维护升级的时候，对些native sql/hql维护麻烦（如数据库类型更换和结构变动）。毕竟我们都不是专业的DBA，所以在设计数据库的时候，更应该倾向于采用领域驱动开发的模式来设计域模型（即是Entity实体）。但很多时候我们可能为了开发过程中的方便操作，往往没对这些实体做任何关联操作，在数据库层就表现为无约束的数据，在hibernate配置中表现为无关联关系的配置。虽然这样在一方面了一起到减轻我们工作量，但另一方面有可能会导致我们对数据的操作可能要做一些额外的处理，更易发生数据的不一致性存储。孰优孰劣，还需要我们在具体项目中再三平衡。
鉴于目前的基础开发框架，还欠缺一个可用的模块开发架构。各人的模块都不能做到独立开发，因为各模块或多或少需要对基础框架配置的改动，还不能做到支持热插拔（即是复制个人开发的模块到指定目录即可植入原先的系统中）。基础框架欠缺自动配置和约定优于配置的机制，无法对新加入的模块进行自动识别和维护，新加入模块必须改动基础框架的配置文件。
解决方案: 在进行封装的时候要优先考虑使用框架内置的功能，除非自己能做到比框架内置功能更好的易用性和效率。封装要考虑对于各个常用javaee标准组件的支持，应该做到支持开发中常用标准组件的调用。在项目编码要充分利用框架的特性，如hibernate进行进行数据orm配置的时候，要适当配置关联关系。在性能不是十分严格要求的数据处理中，对数据操作可以考虑使用hibernate的面向对象的查询操作，简化sql的编写或完全不写sql/hql。加强基础框架的搭建，加强基础框架模块化开发的设计，使得各个分工开发的模块可以解耦的方式接入基础框架中去，而无需改动基础框架的配置，这点可利用SSH底层框架内置的配置文件自动搜索和约定优于配置的机制来轻松实现。
方案优势: 充分利底层用框架的特性，提高项目开发效率。解决各模块与基础框架集成时候必须进行的硬性配置插入的缺点，使得各成员的开发工作可以更为模块化，有利于项目的各模块的持续集成。
4. 使用项目构建工具
存在问题：我们项目基于java ee平台开发，在开发过程中无可避免用到大量的java组件，最为常见的是SSH三大框架，而这三大框架中又需要引入其他java 的组件库，这就出现了一个问题就是可能出现导入同一个组件jar包的不同版本。可能高低本的api略有不同，从而导致出现版本冲突api缺失无法运行的状况。各开发人员在开发各自的独立模块的时候，可能应用了同一的java组件的不同版本的jar包，而各人却一无所知。 各开发人员可能开发环境略有不同，使用的ide可能不是统一类型或配置，可能会出现编译出来的文件内容和结构有略微的区别，当部署到服务器上可能会出现运行异常。无法对整个项目进行统一的质量管理和单元测试，无法综合评测项目完成度和总体单元测试的情况。
解决方案: 使用maven作为项目构建工具，部署统一的项目maven私服。
方案优势: maven可以帮助我们开发者完成整个项目生命周期的管理，在开发过程中起到依赖管理以及整个项目包括编译、测试、打包和部署的作用。尤其是它依赖管理功能在很大程度上解决了前面所说的项目jar包高低版本冲突的问题，确保项目中不会引用不同版本重复的jar包。其次各开发人员的开发的模块可以作为组建可以部署到maven私服上，更为模块化开发提供一个实现途径。
5. 搭建持续集成服务
存在问题：在项目组中一般是各开发成员独立开发各个功能模块后，提交到代码版本控制服务器上，待整个项目全部开发工作完毕，进入测试阶段，又要从版本服务器上检出所有代码编译后再发布到测试服务器上面运行系统的统一的集成测试。在各个开发过程中无法直观的了解到项目系统的完成程度和统一的集成测试无法实时进行，仅靠各开发成员的汇报的进度确定项目进度，无法对客户提供直观的系统完成程度信息。在项目部署上服务器后系统集成测试才发现问题，影响项目交付进度。
解决方案: 使用持续集成服务可以解决上述问题，可供选择服务工具有Jenkins 、Hudson、CruiseControl ,从易用性和可扩展性首选Jenkins 。
方案优势:
1) 可以直接从测试服务器上看到已经部署好的项目系统的效果，而是不是抽象项目的进度数据，可以随时直接操作项目系统，有利于更早的发现问题，修复Bug。
2) 通过减少重复性的动作来节省时间，成本，提高效率。在软件的开发过程中，有许多重复性的活动，这些活动包括代码编译，数据库集成，测试，评审，部署，信息反馈等，持续集成服务都可以依靠编译脚本以定时自动化的方式实现这些操作。
3) 产生可部署的软件，持续集成可以让项目组在任一点上及时提交可以安装的软件包。这是持续集成最可看见的一个益处。