让开发自动化: 持续检查

代码检查可以采用不同的形式。有些企业使用正式的同级评审（peer review），在该评审过程中，开发人员要为代码提供同级评价，并提供改进意见；其他一些企业使用结对编程；还有一些人则考虑使用高级设计决策和推荐的代码改进。有些团队会在将代码提交到版本控制存储库之前，让其他开发人员用 “桌面检查” 的形式审查他们的代码。

不论企业采用哪种方式进行代码检查，有一件事是肯定的：它们几乎都是手工过程。正如我多年所观察到的，手工过程很容易出错，如果工作紧张，就会忘记自己正在做什么。但是，软件检查不必总是手工完成；实际上，有一大堆开源工具和商业工具（我称之为软件检查器），可以用它们很方便地对代码进行静态分析（这些工具也称为静态分析工具）。

使用软件检查器，代码检查可以通过 Ant 或 Maven 这样的构建工具来自动完成。通过使用这种自动化，一些低级的源代码细节（如编码标准、复杂性和重复程度等）的处理成为了机器的职责。这种职责转移通过将重点转向更高级的开发方面（比如设计和长期维护问题）提高了人们手工检查的效率。

关于本系列 作为开发人员，我们的工作就是为用户提供自动化处理；但是，我们中的许多人却忽视了自动化自己的开发过程的机会。出于这个目的，让开发自动化 这一系列的文章专门研究了自动化软件开发过程的实际应用，并教您什么时候 和如何 成功地应用自动化。

用软件检查器来解决问题

软件检查器有很多，范围从复杂的商业工具到简单的开源替代工具。但是，我发现其中三个特别有用，它们是 CheckStyle、CPD 和 JavaNCSS （请参阅 参考资料）：

• CheckStyle 报告与项目预定的编码标准的偏离度。
• CPD 报告代码重复。
• JavaNCSS 可以帮助团队专注于更高级的代码复杂性领域。

什么是持续集成？ 持续集成（CI）是一种实践，可以让团队在持续的基础 上收到反馈并进行改进，不必等到开发周期后期才寻找和修复缺陷。诸如 CruiseControl 之类的检查工具是在后台运行的，它们轮询版本控制存储库，从中寻找更改之处。当发现某一更改时，这类工具就会通过 Ant 执行预定义的构建脚本。持续检查借助持续集成的实践得以改进。

检查器样式标准

我参与了几家公司的委员会，花了很多时间来定义编码标准。有一次，我们定义了几乎没人 遵守的 25 页的编码标准文档。结果，我们的代码审查非常痛苦，因为团队要花时间来挑错，看看开发人员是否使用了两个空格规则（与四个空格规则相对），以及是否将参数声明为 final。如果把这些低级检查工作交给软件检查器，我们会节省许多宝贵的时间。

使用自动的源代码检查工具（如 CheckStyle）可以提供执行可配置规则集的简单途径，规则集可以根据项目的编码标准而定。此外，可以通过 CheckStyle 插件在 IDE 中运行 CheckStyle，CheckStyle 通过它的 Ant 任务或 Maven 插件直接集成到构建脚本中。CheckStyle 发现的所有规则偏离都会以报告的形式显示，清楚地指出哪一个文件违规。除此之外，还可以将 Ant 和 Maven 配置成与 CheckStyle 相呼应，这样，在违反规则时，构建工作就会失败。

例如，清单 1 演示了 Ant 构建脚本的一个代码段，它运行 CheckStyle 生成 HTML 报告。请注意 failOnViolation 属性，在这里它被设为 false。如果将该属性设为 true，则在发现任何 源代码违规时，构建都会失败。