提高你的J2EE项目的质量1

这篇文章中，Jimmy Jarrett建议开发者，特别是团队领导者，需要作哪些事情来确保他们系统的质量。另外还讨论了一些开源工具，它们在测量系统质量方面能够提供帮助，他还特别强调了责任分明的重要性，缺了它，没有开发团队可以获得成功。

　　许多人还在错误的认为基于Java/ J2EE技术的系统仍然在代码维护的问题上纠缠，bug的数量，或者功能的欠缺，或者性能的低下。幸运的是，这些问题已经很少与Java/J2EE技术本身相关联了，与它们真正相关的是缺乏一个关注系统质量的过程。为了确保由一个大型的团队或者跨越多团队开发的，一个大规模的Java/J2EE项目的成功，团队领导者必须:

　　· 使用能够测量质量的工具

　　· 从这些工具中定义一组质量关卡和一些人为因素

　　· 分清对提交、监控的责任界限, 加强实施.

　　这篇文章解释了怎样将这三个策略融入到你的开发战略中，这样才能确保你的团队持续的开发高质量的项目。

　　工具的重要性

　　你听说过一个建筑公司试图建造一所房屋，而没有一把高性能的电锯，电钻或者甚至连最基本的象锤子这样的工具都没有?的确，一所房屋也可以没有今天的先进设备而建起来，但是，建筑将会花更长的时间，并且绝对达不到(使用先进工具)相同的水平。你可以用你的手建起一个小茅屋，但是如果你使用了正确的工具，你就可以建起一座大厦。

　　今天的开发者与那些试图建一所房屋的人几乎一样。对开发者来说工具是最基本的要素，不管是对于提高生产力还是加强质量。开发者使用的工具必须可以让他们在最短的时间内生产出最高质量的代码,这意昧着今天的IDE不再只是用来编写，调试和编译代码的简单工具。对应的，一个IDE必须帮助开发者识别出他们是否遵循合适的编码规范和已知的设计模式，如果他们遵循像Web services这样的工业标准，如果他们的代码追随它的约定，如果它完成每一个需求。别外，如果开发者没有进行持续构建和自动测试的环境，那么一个IDE的能力对加强系统的质量来说就变得更重要了。

　　进入Eclipse IDE看一下，它提供了内置的功能，当使用插件时，可以同时提高代码和系统的质量。Eclipse是一个开放的，可扩展的IDE，无所不为并不专为什么而设计。Eclipse的Java开发环境是开源的，免费的和完全可订制的。Eclipse通过开源的或商业的订制插件来促进新功能的增加。通过使用Eclipse,特别是图1中显示的一组关键的插件，那么对开发者和团队来说，就有可能对基于J2EE或Java的项目质量进行衡量。

　　图1.Eclipse的插件矩阵图

　　如果你不能衡量和监控它，控制一个系统的质量是不可能的。理解系统中允许测量的的关键领域非常重要。它们包括系统的可维护性，可靠性和性能。上述明显没有全部包括全部领域，但是这三项作为确保系统质量的基石是非常合适的。

　　可维护性包括了代码理解或修改的复杂程度，不管它是一个bug修复或是一次升级。良好注释的代码遵守众所周知的编码标准和工业设计标准，它们比那些几乎没有注释的，不遵守开发规范的代码更容易维护。高可维护的代码可以更快地引入更改，这样也就充许业务对新的或变化的需求有更快的响应，最后降低新特性的增加或维护造成的成本。

可靠性表达了一个方法是否遵守它自己的约定，并能够被成功地执行。单元测试可以用来演习一个方法的约定，从而确定代码段的可靠性。单元测试的质量，反过来，也被代码覆盖分析所验证。许多手段可以用来进行测量代码覆盖，包括，但不仅仅是，表达，判断，条件和调用分析。普遍讨论的一个议题是用来确定一个方法的可靠性的覆盖测试的类型和数量。出于这篇文章的目的，简单地说可靠性会随着代码覆盖测试的提高而提高。

　　系统内方法的可靠性是绝对重要的，因为，扩展来说，它就代表了系统的可靠性。其它问题，如性能或可扩展性，会慢慢出现，它们在扩展单元测试和覆盖分析时可以没有。这样，单元测试和覆盖分析毫元疑问地是保证系统稳定性全部的和最终的解决方案。但是，持续稳定地执行方法的能力代表了系统稳定的好的测量棒。

　　性能是典型的依靠每个单元所耗时间进行测量的。从一个系统能够处理多少个请求，到网络呑吐量，到某个系统调用的响应时间，全部都是依靠单元时间作为测量的标准。更为重要的是要知道，扩展开来说，是系统如何运作的。

　　为了达到这样的理解，你可能需要测量所有主要的服务方法、或者通过高使用频率，长调用堆栈，或者那些代表了核心构造中最普遍的交易通路来体现的问题域。第一步为性能提供了不一样的舒适度。对大型系统来说，性能应该在开发过程中被持续的维护和监控，以尽早地确定障碍并且避开生产环境下不可预知的错误。

　　现在，让我们来看一下Eclipse和它的插件是如何帮助开发团队来测量任何基于Java或者J2EE系统的维护性、可靠性、和性能的。

　　代码生成:可维护性

　　代码生成是确保一致性和可重复代码质量的最佳方法之一，它不同于基于类型的方式。XDoclet是目前生成Java源代码的工业标准。XDoclet是一个开源的，免费的库，它解析代码，寻找指定的Javadoc标记(元数据)，然后用它来生成其它的Java源程序。

　　XDoclet包含了一组Javadoc标记，它们可以用来生成大多数的的可重复代码，这些代码在主流的基于Java/J2EE的系统中都可以找到，如JavaBean和EJB的home以及remote类，它甚至提供某些专有信息:如Borland Enerprise Server,JBoss, Orion, Resin, Sun Java System Application Server,Weblogic和Websphere。它也支持许多其它技术，如Hibernate, JDO(Java数据对象)，和Castor。如果这些还不够，XDoclet还可以扩展，允许开发者创建自己的定制标记来生成自制代码。使用XDoclet，让它为你生成代码，你可以在重复的编码中避免代码错误和bug。

　　代码度量:可维护性

　　因为代码容量过大，所以做不到可视地监控整个代码库。不必把每一行都过一遍，度量可确认出存在或潜在的问题。Eclipse的Metrics插件是一个开源的，免费的工具，它可以每一个类，每一个包或者每一个项目级别上生成度量值。为了便于保存历史记录，结果会输出在一个XML文件中。它也包含了一个Ant任务，可以用它来生成上述XML。

　　Eclipse的Metrics插件提供了超过23种类型的度量。最重要的一些度量包括接口的数量，深度继承树，重载的方法数量，McCabe的三级复杂度，传入藕合，传出藕合和抽象。默认地，Metrics图用蓝色显示合适，用红色显示违规。任何显示红色的部份都代表了一个可能的问题，需要你回头确认。插件有它自己的视图，并在后台运行;这样，它不可以被团队领导者在阶段结束时使用，也可以被开发人员用于自己的代码。

　　代码覆查:可维护性

　　代码覆查是一种有效的练习可以用来确保代码质量，也可以用来在编码风格和编码的最佳实践方面指导开发者。Jupiter是一个开源的，免费的工具，可以进行基于团队的代码覆查。Jupiter使用XML文件来跟踪单个的团队成员覆查，覆查使用一个覆查ID和覆查者ID(覆查ID是被团队覆查所共享的)。这些文件被加入到源代码控制中并对其它开发者可用，允许同步的进行多个覆查，并不需要服务端管理。

　　每个团队成员使用一个XML文件来从源码控制中检入检出，来看一下什么东西需要整理或者其它成员已完成的整理。使用Jupiter可以免除通常在新开发中要严格遵守的bug跟踪制度。Jupiter把队员解放了，他们可以在他们方便的时候进行代码覆查，而不是强迫他们正在解决一个问题时还去参加代码覆查会议。

　　坚持标准:可维护性

　　开发标准存在的目的是避免过去的错误重犯。另外，它也确保了代码的一致性和对于将来会维护这些代码的人员的更大的可读性。Eclipse内置了一个遵循Java编码约定的格式化器。虽然这很棒，但一个格式化器对于确保产出高质量的代码是不够的。

　　Checkstyle建于Eclipse的代码格式化的基础之上，增加了更多的语法检查。它能够指出不合式的代码块，编码错误，重复代码和一些测量违规。更好的是，CheckStyle是完全可定制的，允许用户裁剪检查的类型和组织内部开发标准的严格等级。默认的Checkstyle配置文件是全面的。甚至，我建议开发者投资一点时间在定制这个插件上面，让它完全符合组织的开发需要。定制完成后，Checkstyle的配置文件可以被导出，用到多个项目中。Checkstyle的执行结果是显示为问题视图，它能被过滤和分类。结果可以按文件夹，工作集或者源文件级查看，可以让开发者看到整个编码，子系统或者单个类的质量。

　　如果你的团队正中进行Web服务的开发，那么WSVT(Web服务验证工具)是一个必须的插件。WSVT可以确认一个Web服务是否符合WS-I(Web服务交互)的基本规范。开发者中需右键点击在一个WSDL(Web服务描述语言)文件上，它就可以对WSDL进行验证，并生成一个可定制的视图报告，来显示出现的冲突。作为额外的好处，WSVT插件监控TCP/IP通讯并且观察、捕捉和验证SOAP消息。WSVT插件因此可以确保接口层和消息层的合规性。