提高你的J2EE项目的质量

这篇文章中，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插件因此可以确保接口层和消息层的合规性。

功能测试:可靠性

　　Eclipse集成了Ant和JUnit。Ant是创建基于Java的应用的实事上的工业标准。JUnit基于Java的生成单元测试的框架。

　　开发者可以建立在Eclipse中运行的单独的JUnit测试，它为JUnit的运行结果提供了特殊的视图，或者使用Ant的JUnit或JUnitReport任务。JUnitReport Ant任务生成一个可视化的HTML报告，它可以根据定制来代表整个系统的测试或者某一个测试。HTML报告是一种非常好的报表，它可以服务测量项目的质量，可以作为历史记录保存。使用JUnit进行单元测试，开发者必须确定他们的方法符合他们的声明，这样就避免了不规范导致的bug的升级。

　　代码覆盖:可靠性

　　当开发者写了单元测试，他们必须了解这些单元测试提供了大程度的代码覆盖。

　　GroboCodeCoverage是一个开源的工具，它和Ant集成在了一起，通过使用任务来生成覆盖报告。可以生成单个的报告，如行计数报告和方法计数报告，它们分别提供了代码行和方法的覆盖百分比。但是，这个工具的精华是它的摘要覆盖报告。这个报告模仿了Javadoc的结构，提供了一种专业的，高质量的报告，可以作为历史文档保存起来。随着项目的进展，参考这个报告就可以看出在这一过程中代码覆盖是在增加还是减少。通过使用GroboCodeCoverage开发者可以确保他们最关键的代码段被完全的测试过，并发现缺乏覆盖的细小的角落。使用这些信息，他们可以增加或更新现有的JUnit测试，从而提高系统的可靠性。

　　Profiler:性能

　　当项目接近完成阶段时，开发者开始更多的思考性能。基于Eclipse的Profiler是一个开源的，免费的监测工具，它针对开发者需要解决的普通的性能问题提供了很多特性。它显示了线程，堆大小，堆dump，方法调用，方法次数，每个包的调用和线程调用树，通过它开发者可以看到时间在调用流中被花费在了哪些地方。基于Eclipse的Profiler帮助开发者了解应用的瓶项在哪里发生，让他们在将产品提交给QA(质量保证)部门或投放生产之前更正错误。

　　使用工具控制质量的好处

　　上述所列工具，可以让开发者监控，测量，跟踪和确认需提高的领域。没有这些工具，开发者就会使用他们自己的发明，并且整个团队将会进行自己的代码覆查，这些很显然是很少并且非常因难地对其进行跟踪的。更为重要的是，这些工具不仅能够为开发者使用，也能为团队领导使用。团队领导不再手工地察看代码或者定期地召开代码覆查会议。一个团队领导可以使用这些工具来测量和监控整个的编码，从而在整个开发周期同控制和确认系统的质量。

　　改变的垫脚石

　　他们说罗马不是一天内建成的，这同样也适用于为你的基于J2EE或Java的项目实现质量控制。试图从头引入一种处理可能会以失败收场，因为许多人反对改变，开发人员也不例外。一个过程的新方面应该通过时间慢慢地引入，这样才能生根和得到接受。通过逐渐引入质量关卡可以确保这一过和得到接受。

　　在开发者社区内，关卡也被称作检查站，覆查或质量关卡。抛开语义学不说，一个关卡是开发过程中的一个认识点，包括可交付的某种形式的半成品和对其进行覆查的一组风险承担者。从开发到QA，如不存在QA,那么到生产的过程必须通过关卡来提高代码的质量。项目的历史和它的状态，无论它是刚开始还是正在进行，应该首先说明使用什么样的关卡和工具。

　　在介绍关卡给开发团队之前，请花点时间确认你的项目需要引入的关卡的顺序。每个项目的需要是不同的，因为它的成员的强项和弱项不同。确认项目可以从中获益最大的质量提高是在哪里，然后应用合适的关卡来认识它们。图2显示了使用Eclipse的插件可以获得的质量提高

　　图2.每一种开发关卡带来的质量提高

　　当你确定了你要引进的关卡的顺序后，将你的团队成员聚在一起，给他们看一下这些工具和插件，以及它们的能力。给他们这些插件的链接或在局域网中共享出来，然后确认他们每人都安装了插件。这一策略不能保证开发者一定会用它们，但提高这样的机会。必竟，如果不安装的话就根本不会使用这些工具了。一旦开发者安装了这些工具，开始讨论你打算具体引入的每一个关卡。

Checkstype覆查关卡

　　讨论Checkstyle的配置设置并且它们为什么被使用。让你的开发者知道所有的错误必须被纠正并讨论警告是否应该被纠正(这是可选的，基于Checkstyle如何配置)。确认开发者了解他们必须使用Checkstyle，对其使用会被轮流检查。

　　JUnit覆查关卡

　　一个JUnit报告应该在每一个构建过程结束时生成，因为它被用来持续地测量系统的可靠性。开发者在检入他们的代码之前必须对他们的代码改变进行单元测试。将历史报告放在每人都可以看到的地方，并和新报告比较以看出项目的进展。

　　Metrics覆查关卡

　　讨论测量视图所有配置的能力(那些重要的和那些被禁用的)。确认开发者使用同样的方法配置了Metrics插件，他们得到的一同样的视图。请他们在编码时打开这个插件，这样当改变代码时可以迅速地检查Metrics视图。再一次，提醒团队代码测量会在每一个构建阶段结束时被监控。

　　Jupiter团队覆查关卡

　　Jupiter覆查需要介绍一些形式的覆查过程。一个命名的覆查ID需要建立，同时提供进入和分解责任。一旦覆查过程完成定义，和整个团队讨论过程。经验的方法是，有一个持续的覆查ID,它可以进行所有的工作，然后为每一个特定的覆查建一个ID。第一次，要求团队单个类中的测试代码。然后找到问题，并确认解决它。后续的过程需要团队成员检查正在进行的覆查ID，并进行团队领导指定他们作的特定代码的覆查。

　　GroboCodeCoverage报告覆查关卡

　　确认和解释覆盖的期望值给你的团队。能过GroboCodeCoverage列出将要生成的报告的类型，当报告生成时，它们将会被存储在可以随时进行比较的地方。至少，源代码覆盖报告应该作为中心报告来生成出最主要的信息。

　　测量和通知

　　通过慢慢地引入关卡，开发者将有时间接受和适应新的工具和过程。这样，新插件的使用机会就提高了，反过来也就提高了代码和系统的质量。确认所有站生成的报告将会email给团队成员。Email可以包含内容或指向内容的链接，重要的是开发可以收到他们工作质量的反馈。

　　责任分明

　　路铺了以后，有人走才有用。这篇文章中所述的测量和关卡的好处只有当他们被使用时才会体现。不要希望你只是简单地告诉他们使用插件就带来质量的提升，如果你不确认他们使用的话。责任分明是必须的，如果想要得到上述好处的话。

　　伴随着改变，一些人肯定会拥护工具和关卡的使用。拥护者需要是负责代码质量的人;可能是项目经理，团队领导，或者设计师，这取决于团队是如何组织的。拥护者确保开发者使用工具和关卡，并且使用工具进行了并键的覆查和对信息的监控。

　　最后，开发者必须对使用插件和关卡负责，这样都会对责任分明带来帮助。通过在每一阶段结束时计划一个简短的会议或者将结果email给团队来确认使用了关卡。满足带来混乱，工作和纪律质量。如果开发者知道他们的工作和质量正在被监控，那么他们就会更倾向于使用工具来提高工作质量。通过确认开发者使用了工具，整个项目的质量才会自然而然地增长。

　　结论

　　任何的开发项目都很复杂，基于Java/J2EE的项目也不例外。控制和提高质量的唯一方法就是持续地测量它，并努力地提高它。如果没有合适的标准和实践被引入，那么系统的可维护性，可靠性和性能都会受到损害。

　　但是，如果合适的工具被使用，需要的关卡被引入，开发者对他们自己工作的质量负起责任，那么结果将会是系统中更少的bug，更多地一致性和可维护的代码，这样才能满足对它的期望。