編寫線程安全的類很難，而分析現有類的線程安全性更難，增強類使其仍然保持線程安全也很難。以隱含假定、不變式以及預期用例（雖然在開發人員的頭腦中很清晰，但是沒有以設計筆記、注釋或者文檔的方式記錄下來）的方式編寫完類之后，人們很快就不再了解類的工作方式（或者應該如何工作），現有代碼總是比新代碼難以使用。
需求：更好的代碼審核工具
當然，確保高質量代碼的最佳時機就是在編寫代碼時，因為在這個時期您最了解它的組織方式。關于如何編寫高質量代碼可以找到很多建議（閱讀本欄目即可�。�，但是未必能從頭編寫所有代碼或花很多時間來編寫它。那么在這種情況下該怎么辦？開發人員通常喜歡重新編寫代碼（畢竟，與修復他人的代碼或修復自己編寫但 bug 很多的代碼相比，編寫新代碼有趣得多），但是這也是一種奢侈，并且通常只是用今天已知的錯誤與明天未知的錯誤交換。您需要的是下面這種工具：分析和審核現有的代碼庫以幫助開發人員進行代碼審核并找出 bug。
我很高興地說，隨著 FindBugs 的引入，在自動代碼檢測和審核工具方面已經取得重大進步。到目前為止，大多數檢測工具要么極力試圖證明程序是正確的，要么注重一些表面問題，如代碼的格式編排和命名規則，最多還關注一些簡單的 bug 模式，如自賦值、未使用的域或潛在的錯誤（如未使用的方法參數，或可以聲明為私有或保護的方法被聲明為公共的）。但是 FindBugs 不同，它利用字節碼分析和很多內置的 bug 模式檢測器來查找代碼中的常見 bug。它可以幫助您找出代碼的哪些位置有意或者無意地偏離了良好的設計原理。（有關 FindBugs 的介紹，請參閱 Chris Grindstaff 的文章，“ FindBugs，第 1 部分: 提高代碼質量”和“ FindBugs，第 2 部分: 編寫自定義檢測器”。）
設計建議和 bug 模式
對于每種 bug 模式，設計建議中都存在相應的預防要素，用于告誡我們避免這種 bug 模式。因此如果 FindBugs 是 bug 模式檢測器，那么它理所當然可以用作審核工具，衡量代碼與一組設計原理的符合程度。 Java 理論與實踐的很多期文章都專門講述設計建議的具體要素（或相應的 bug 模式）。在這一期，我將解釋 FindBugs 如何確�，F有代碼庫遵循設計建議。讓我們以新方式重復前面的一些建議，并了解在沒有遵守這些建議時，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 檢測器將檢測如下有問題的重載：
文章來源于領測軟件測試網 http://www.kjueaiud.com/
