编写线程安全的类很难，而分析现有类的线程安全性更难，增强类使其仍然保持线程安全也很难。以隐含假定、不变式以及预期用例（虽然在开发人员的头脑中很清晰，但是没有以设计笔记、注释或者文档的方式记录下来）的方式编写完类之后，人们很快就不再了解类的工作方式（或者应该如何工作），现有代码总是比新代码难以使用。
需求：更好的代码审核工具
当然，确保高质量代码的最佳时机就是在编写代码时，因为在这个时期您最了解它的组织方式。关于如何编写高质量代码可以找到很多建议（阅读本栏目即可！），但是未必能从头编写所有代码或花很多时间来编写它。那么在这种情况下该怎么办？开发人员通常喜欢重新编写代码（毕竟，与修复他人的代码或修复自己编写但 bug 很多的代码相比，编写新代码有趣得多），但是这也是一种奢侈，并且通常只是用今天已知的错误与明天未知的错误交换。您需要的是下面这种工具：分析和审核现有的代码库以帮助开发人员进行代码审核并找出 bug。
我很高兴地说，随着 FindBugs 的引入，在自动代码检测和审核工具方面已经取得重大进步。到目前为止，大多数检测工具要么极力试图证明程序是正确的，要么注重一些表面问题，如代码的格式编排和命名规则，最多还关注一些简单的 bug 模式，如自赋值、未使用的域或潜在的错误（如未使用的方法参数，或可以声明为私有或保护的方法被声明为公共的）。但是 FindBugs 不同，它利用字节码分析和很多内置的 bug 模式检测器来查找代码中的常见 bug。它可以帮助您找出代码的哪些位置有意或者无意地偏离了良好的设计原理。（有关 FindBugs 的介绍，请参阅 Chris Grindstaff 的文章，“ FindBugs，第 1 部分: 提高代码质量”和“ FindBugs，第 2 部分: 编写自定义检测器”。）
设计建议和 bug 模式
对于每种 bug 模式，设计建议中都存在相应的预防要素，用于告诫我们避免这种 bug 模式。因此如果 FindBugs 是 bug 模式检测器，那么它理所当然可以用作审核工具，衡量代码与一组设计原理的符合程度。 Java 理论与实践的很多期文章都专门讲述设计建议的具体要素（或相应的 bug 模式）。在这一期，我将解释 FindBugs 如何确保现有代码库遵循设计建议。让我们以新方式重复前面的一些建议，并了解在没有遵守这些建议时，FindBugs 如何帮助检测。
关于异常的争论
在“ Java 理论与实践: 关于异常的争论”中，反对检查型异常的一个论据是：“摸索”（也就是捕获）这种异常太容易了，并且它既不采取修正行为，也不抛出其他异常，如清单 1 所示。在原型设计中，有时仅仅为了使程序编译，编写空的 catch 块，目的是以后返回并填充某种错误处理策略，这时经常出现这种“摸索”。虽然一些人提供发生这种情景的频率，是为了作为例子说明 Java 语言设计采用的异常处理方法的不易操作性，但是我认为这仅仅是错误地使用了正确的工具。FindBugs 可以方便地检测和标记这些空的 catch 块。如果想要忽略这种异常，可以方便地给该异常添加描述性注释，这样读者就知道您是有意的忽略它，而不是仅仅忘了处理。
清单 1. “摸索”异常
try { mumbleFoo(); } catch (MumbleFooException e) { }
哈希
在“ Java 理论与实践： 哈希”中，我略述了正确地重载 Object.equals() 和 Object.hashCode() 的基本规则，特别是相等对象（根据 equals() ） 的 hashCode() 值必须相等。虽然只要了解了这项规则，遵守起来就相当简单（并且有些 IDE 包含一些向导，用于以一致的风格为您定义这两个方法），但是如果重载了其中一个方法，而忘记重载另一个方法，那么通过检测很难找出 bug，因为错误并非位于存在的代码中，而是位于不存在码中。
FindBugs 有一个检测器用于检测这个问题的很多实例，如重载了 equals() 但没有重载 hashCode() ，或重载了 hashCode() 但没有重载 equals() 。这些检测器是 FindBugs 中最简单的，因为它们只需要检查该类中一组方法签名，并确定是否同时重载了 equals() 和 hashCode() 。还可能错误地使用 Object 之外的参数类型定义 equals() ；虽然这个构造是合法的，但是它的行为和您想像的不同。Covariant Equals 检测器将检测如下有问题的重载：
public void boolean equals(Foo other) { ... }
文章来源于领测软件测试网 https://www.ltesting.net/