Checkstype覆查关卡
讨论Checkstyle的配置设置并且它们为什么被使用。让你的开发者知道所有的错误必须被纠正并讨论警告是否应该被纠正(这是可选的，基于Checkstyle如何配置)。确认开发者了解他们必须使用Checkstyle，对其使用会被轮流检查。
JUnit覆查关卡
一个JUnit报告应该在每一个构建过程结束时生成，因为它被用来持续地测量系统的可靠性。开发者在检入他们的代码之前必须对他们的代码改变进行单元测试。将历史报告放在每人都可以看到的地方，并和新报告比较以看出项目的进展。
Metrics覆查关卡
讨论测量视图所有配置的能力(那些重要的和那些被禁用的)。确认开发者使用同样的方法配置了Metrics插件，他们得到的一同样的视图。请他们在编码时打开这个插件，这样当改变代码时可以迅速地检查Metrics视图。再一次，提醒团队代码测量会在每一个构建阶段结束时被监控。
Jupiter团队覆查关卡
Jupiter覆查需要介绍一些形式的覆查过程。一个命名的覆查ID需要建立，同时提供进入和分解责任。一旦覆查过程完成定义，和整个团队讨论过程。经验的方法是，有一个持续的覆查ID,它可以进行所有的工作，然后为每一个特定的覆查建一个ID。第一次，要求团队单个类中的测试代码。然后找到问题，并确认解决它。后续的过程需要团队成员检查正在进行的覆查ID，并进行团队领导指定他们作的特定代码的覆查。
GroboCodeCoverage报告覆查关卡
确认和解释覆盖的期望值给你的团队。能过GroboCodeCoverage列出将要生成的报告的类型，当报告生成时，它们将会被存储在可以随时进行比较的地方。至少，源代码覆盖报告应该作为中心报告来生成出最主要的信息。
测量和通知
通过慢慢地引入关卡，开发者将有时间接受和适应新的工具和过程。这样，新插件的使用机会就提高了，反过来也就提高了代码和系统的质量。确认所有站生成的报告将会email给团队成员。Email可以包含内容或指向内容的链接，重要的是开发可以收到他们工作质量的反馈。
责任分明
路铺了以后，有人走才有用。这篇文章中所述的测量和关卡的好处只有当他们被使用时才会体现。不要希望你只是简单地告诉他们使用插件就带来质量的提升，如果你不确认他们使用的话。责任分明是必须的，如果想要得到上述好处的话。
伴随着改变，一些人肯定会拥护工具和关卡的使用。拥护者需要是负责代码质量的人;可能是项目经理，团队领导，或者设计师，这取决于团队是如何组织的。拥护者确保开发者使用工具和关卡，并且使用工具进行了并键的覆查和对信息的监控。
最后，开发者必须对使用插件和关卡负责，这样都会对责任分明带来帮助。通过在每一阶段结束时计划一个简短的会议或者将结果email给团队来确认使用了关卡。满足带来混乱，工作和纪律质量。如果开发者知道他们的工作和质量正在被监控，那么他们就会更倾向于使用工具来提高工作质量。通过确认开发者使用了工具，整个项目的质量才会自然而然地增长。
结论
任何的开发项目都很复杂，基于Java/J2EE的项目也不例外。控制和提高质量的唯一方法就是持续地测量它，并努力地提高它。如果没有合适的标准和实践被引入，那么系统的可维护性，可靠性和性能都会受到损害。
但是，如果合适的工具被使用，需要的关卡被引入，开发者对他们自己工作的质量负起责任，那么结果将会是系统中更少的bug，更多地一致性和可维护的代码，这样才能满足对它的期望。
