提高你的J2EE项目的质量2

　　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，更多地一致性和可维护的代码，这样才能满足对它的期望。