近两年，开放源码项目发展日益壮大，出现了很多有着广阔用户群体的项目与产品，它们在企业应用开发中正在发挥着越来越大的作用。本文以基于J2EE架构的企业应用开发为例，探讨了如何在项目中深入运用JAVA开发源码项目与工具。
企业应用开发目前面临的主要问题
企业应用是指服务于商业目的，处理企业业务信息、数据的软件系统。虽然随着dot COM热潮逐渐冷却，企业开始谨慎考虑自己在应用系统开发方面的投入，但是毕竟企业的业务流程需要专门的信息系统处理，从而提高自动化程度、减少中间环节、加快信息处理速度。因此，目前国内的企业应用项目开发还是日益火爆，尤其在电子政务、CRM、SCM等领域更是如此。
但是，不论企业应用开发是采用自行开发或者委托系统集成商进行开发，都存在着下面一些情况：
大部分项目超时或者超出预算；
项目在部署以后BUG很多，而且修改的周期比较长；
对于系统集成商来说，下面的情况更是比较普遍：
没有统一的FRAMEWORK，每个项目都会重新设计ARCHITECTURE；
项目开发过程的自动化程度和重复步骤不是很多，人为引入的BUG很多；
开放源码项目现状
开放源码运动在90年代开始日益发展，目前已经成为软件业内不可低估的一股势力，比较著名的有Linux,、Apache、Tomcat、MySQL等。目前，开放源码的潮流已经超出了操作系统、数据库管理系统和WEB服务器等系统开发领域，开发在企业应用开发中寻找新的领地。尤其是对于企业应用开发的框架和CASE工具，开放源码项目都有很优秀的解决方案。
国外开放源码项目的集中地有www.apache.org以及www.sourceforge.net，其中，前者为大家奉献了著名的Apache、Tomcat、Struts、Axis；而后者是最著名的开源项目中心。同时，国内自90年代末开始也有很多人投入到开源项目的开发，比较集中的网址是 "共创软件联盟"(www.cosoft.org.cn) 等等，他们除了提供各种CASE工具以外，还有一些项目是专注于特定领域的解决方案开发，如CRM等。
JAVA开发源码项目与工具的应用
对于目前企业应用开发竞争日益激烈，需求变更频繁，各个系统集成商都面临巨大的生存压力。其中有两个方面表现尤其突出：
没有统一的软件开发过程或者照搬重量级的软件开发过程，例如RUP等，但是往往由于时间等压力的影响，并不能切实执行；
大部分企业仍然没有摆脱手工作坊期间的做法，每个项目或者产品由于管理人员或者团队的不同，重新设计系统框架，浪费大量的时间在结构验证与调整上；
企业应用系统的开发中，需求的变更是项目中唯一不变的东西，而且，为了保持开发的一致性和利益最大化，系统集成商需要与客户保持长期的合作。因此，采取演进式敏捷软件开发，可以更好的保证项目质量。在所有的敏捷软件开发方法中，XP是目前应用最为广泛的一种。它是一种高度动态的过程，它通过非常短的迭代周期来应对需求的变化；沟通、简单、反馈和勇气是它的四大核心价值。同时，它集中了业界的很多最佳实践，目前已经有18条之多，XP强调通过严格执行全部的最佳实践来获得"极限"效果。
同时，出于复用和效率的考虑，尤其是对于系统集成商，企业应用系统应该具有自己的框架和结构。拥有具有良好性能、经过项目验证的系统框架，结合有效的软件开发过程，系统集成商可以快速、成功地开发企业应用系统。
为了更好的开发成功的系统，系统集成商们可以试着从以下两个方面着手解决问题：
结合开源工具的支持，在组织内部实施"敏捷软件开发方法"；
为核心业务领域建立灵活、有效的Framework；
由于目前很多企业应用是采用基于J2EE技术的网络应用程序开发，因此，下面主要介绍基于JAVA的开源项目、工具的应用。
1. 开源工具与XP
XP的12条最佳实践，对于所有的企业应用开发商而言，由于组织和文化的不同，不可能全部应用，但是，下面几个实践是有条件逐步实施的：
代码规范：CODE STANDARD
测试驱动开发：TEST-DRIVEN DEVELOPMENT
日构建：DAILY BUILDING
持续集成：CONTINUOUS INTEGRATION
小步发布：SMALL RELEASE
每日晨会：DAILY MEETING
每周40小时工作：40-HOURS A WEEK
其中，CODE STANDARD和TDD是CONTINUOUS INTEGRATION、DAILY BUILDING和SMALL RELEASE的基础；而DAILY MEETING和40-HOURS A WORK是单独的实践过程，可以与其他的实践想结合，增强项目小组的沟通，激发士气。
需要说明的是以上最佳实践并非XP所独有，而是被最多的软件开发方法所应用，其中"日构建"就在微软的软件开发方法中正式出现过。
代码规范
虽然大部分的企业在一定程度上推行代码标准与规范，而且对于使用JAVA的应用程序开发，也有SUN的推荐编码规范，但是，实际的情况并不理想。
主要的原因在于：一方面，开发人员的习惯势力很大；另一方面，代码审查的力度不够。如果能够借助工具，从一定程度上帮助进行代码标准的执行情况检查，那么代码审查就可以着重检查程序的逻辑和性能等方面。
开源产品CheckStyle (http://sourceforge.net/projects/checkstyle) 可以帮助开发组织解决代码标准审查的问题。
目前的最新版本为3.0，它提供了两种运行方式：一种是命令行；一种是与Ant结合(Ant自1.5以后提供的OPTIONAL TASKS中有对于CheckStyle的支持)。同时，SourceForge中有对于JBuilder等流行IDE的插件支持，可以定义Global、Project级别上的属性文件， 但是，目前只是支持2.42版本。
在3.x版本之前，CheckStyle的配置信息写在Property File中；而在3.x之后，配置信息为XML文件，配置更加灵活。3.0的发布版本中提供了针对Sun Code Conventions的特定Check File，可以参考使用。
建议执行情况：
手动执行：开发人员在IDE中手动触发CheckStyle检查或者代码审查时由审查者手动执行；
自动执行：将CheckStyle与源码控制系统(CVS)结合，在源码Checkin的时候进行规则判断，如果不符合，则不允许代码进入系统。
