文章目錄
本文總結參考資料：https://baike.baidu.com/item/FindBugs/4111190
TODO項：FindBugs使用總結
FindBugs簡介
（1）finbugs：java代碼靜態分析工具，它檢查類或者 JAR 文件，將字節碼與一組缺陷模式進行對比以發現可能的問題。
（2）FindBugs不注重樣式或者格式，它試圖只尋找真正的缺陷或者潛在的性能問題。
爲什麼使用靜態分析工具
（1）有了靜態分析工具，就可以在不實際運行程序的情況對軟件進行分析。
（2）檢測完畢可生成一份詳細的報告，藉由這份報告，可以發現許多代碼中間潛在的bug。
（3）比較典型的，如引用了空指針(null pointer dereference), 特定的資源(db connection)未關閉，等等。如果用人工檢查的方式，這些bug可能很難纔會被發現，或許永遠也無法發現，直到運行時發作…當除掉了這些典型的(classic) bug後，可以確信的是，我們的系統穩定度將會上一個新的臺階。
FindBugs的使用
在FindBugs的GUI中，需要先選擇待掃描的.class文件(FindBugs其實就是對編譯後的class進行掃描，藉以發現一些隱藏的bug。)。如果你擁有這些.class檔對應的源文件，可把這些.java文件再選上，這樣便可以從稍後得出的報告中快捷的定位到出問題的代碼上面。此外，還可以選上工程所使用的library，這樣似乎可以幫助FindBugs做一些高階的檢查，藉以發現一些更深層的bug。
FindBugs常見的兩種使用時機
（1）開發階段
當Developer完成了某一部分功能模塊開發的時候(這通常是指代碼撰寫完成，並已debug通過之後)，可藉由FindBugs對該模塊涉及的java文件進行一次掃描，以發現一些不易察覺的bug或是效能問題。交付新版的時候，開發團隊可以跑一下FindBugs，除掉一些隱藏的Bug。FindBugs得出的報告可以作爲該版本的一個參考文檔一併交付給測試團隊留檔待查。
在開發階段使用FindBugs，一方面開發人員可以對新版的品質更有信心，另一方面，測試人員藉此可以把更多的精力放在業務邏輯的確認上面，而不是花大量精力去進一些要在特殊狀況下才可能出現的BUG(典型的如Null Pointer Dereference)。從而可以提高測試的效率。
（2）維護階段
這裏指的是系統已經上線，卻發現因爲代碼中的某一個bug導致系統崩潰。在除掉這個已暴露的bug之後，爲了快速的找出類似的但還未暴露的 bug，可以使用FindBugs對該版的代碼進行掃描。當然，在維護階段使用FindBugs往往是無奈之舉，且時間緊迫。此外，如果本來在新版交付的時候就使用過FindBugs的話，往往意味着這種bug是FindBugs還無法檢測出的。這也是FindBugs侷限的地方。
FindBugs出到目前的版本，功能已經相當強大，不過也有待完善的地方。從實際使用來看，有一些隱藏的bug並不能靠FindBugs直接發現。
那麼，可不可以撰寫一個新的 Detector，來發現這種將一個未初始化的reference傳來傳去而形成的潛在的bug呢？理論上來講，應該是可以的。這個 Detector目前還未實現。哪位如果有興趣的話，可以參考FindBugs, Part 2: Writing custom detectors（擴展閱讀）這篇文章，幫忙實現這個Detector。實現一個新的Detector，便可以檢測出一種新型的bug，這樣不知又可以幫開發人員省去多少人工檢查的時間，功德無量啊。
FindBugs的侷限性
FindBugs也不能發現非java的Bug。
對於非java撰寫的代碼，如javascript，SQL等等，要找出其中可能的bug，FindBugs是無能爲力的。
當然，javascript中的bug似乎還不至於使系統崩潰，而SQL中的bug往往又跟業務邏輯相關，只要測試仔細一些應該是可以發現的。
爲什麼應該將 FindBugs 集成到編譯過程中？
經常問到的第一個問題是爲什麼要將 FindBugs 加入到編譯過程中？
雖然有大量理由，最明顯的回答是要保證儘可能早地在進行編譯時發現問題。
當團隊擴大，並且不可避免地在項目中加入更多新開發人員時，FindBugs 可以作爲一個安全網，檢測出已經識別的缺陷模式。
我想重申在一篇 FindBugs 論文中表述的一些觀點。如果讓一定數量的開發人員共同工作，那麼在代碼中就會出現缺陷。像 FindBugs 這樣的工具當然不會找出所有的缺陷，但是它們會幫助找出其中的部分。現在找出部分比客戶在以後找到它們要好——特別是當將 FindBugs 結合到編譯過程中的成本是如此低時。
一旦確定了加入哪些過濾器和類，運行 FindBugs 就沒什麼成本了，而帶來的好處就是它會檢測出新缺陷。如果編寫特定於應用程序的檢測器，則這個好處可能更大。
生成有意義的結果
重要的是要認識到這種成本/效益分析只有在不生成大量誤檢時纔有效。換句話說，如果在每次編譯時，不能簡單地確定是否引入了新的缺陷，那麼這個工具的價值就會被抵消。
分析越自動化越好。如果修復缺陷意味着必須吃力地分析檢測出的大量不相干的缺陷，那麼您就不會經常使用它，或者至少不會很好地使用它。
確定不關心哪些問題並從編譯中排除它們。也可以挑出；
確實關注的一小部分檢測器並只運行它們。另一種選擇是從個別的類中排除一組檢測器，但是其他的類不排除。FindBugs 提供了使用過濾器的極大靈活性，這可幫助生成對團隊有意義的結果。
確定用 FindBugs 的結果做什麼
可能看來很顯然，但是您想不到我參與的團隊中有多少加入了類似 FindBugs 這樣的工具而沒有真正利用它。讓我們更深入地探討這個問題——用結果做什麼？明確回答這個問題是困難的，因爲這與團隊的組織方式、如何處理代碼所有權問題等有很大關係。
不過，下面是一些指導：
可以考慮將 FindBugs 結果加入到源代碼管理（SCM）系統中。一般的經驗做法是不將編譯工件（artifact）放到 SCM 系統中。不過，在這種特定情況下，打破這個規則可能是正確的，因爲它使您可以監視代碼質量隨時間的變化。
可以選擇將 XML 結果轉換爲可以發送到團隊的網站上的 HTML 報告。
轉換可以用 XSL 樣式表或者腳本實現。有關例子請查看 FindBugs 網站或者郵件列表。
Eclipse安裝FindBugs插件
1.點擊Eclipse “Help->InstallNew Software” 的Install New Software;
2.點擊“Add”，然後在彈出框“Name”輸入“findBugs”，“Location”輸入“http://findbugs.cs.umd.edu/eclipse”，
點擊“OK”
3.選擇對應插件，然後點擊“next->next->finish”;
4.完成安裝之後重啓eclipse，右擊項目文件或目錄，會發現多了Findbugs的菜單，如下圖：
IDEA安裝FindBugs插件
1.在IDEA->File->Setting->Plugins搜索框中輸入findbugs進行下載安裝；
2.重啓IDEA;
3.檢查IDEA是否成功安裝FindBugs, IDEA是否會出現findbugs的圖標，如下圖：
FindBugs使用總結
TODO
總結
FindBugs不過是一個工具。作爲開發人員，當然首先要在編程的時候努力避免引入bug，而不要依賴於某個工具來爲自己把關。不過由於代碼的複雜性，一些隱藏的bug確實很難靠咱們的肉眼發現。這時，應用一些好的工具或許就可以幫你發現這樣的bug。這便是FingBug存在的價值。