今天的軟件開發團隊承受著巨大的壓力；市場對高質量、安全版本的需求不斷加快，而安全威脅也變得越來越復雜。考慮到產品故障和安全漏洞的高成本，在整個軟件開發過程中解決這些風險比以往任何時候都更加重要。需要盡早發現潛在問題，以防止發布延遲或更糟糕的是，發布后失敗。

幸運的是，有許多工具可以幫助開發人員管理這些風險，幫助在開發階段早期識別潛在問題，此時問題的破壞性較小且更容易修復。開發人員可以輕松訪問它們，并且在許多開發環境中易于使用。這適用于使用任何語言進行編程的開發人員；但是，我們在本次討論中專注于 Java。

靜態分析有助于降低風險

在考慮 Java 或其他方面的靜態分析工具時，了解這些工具是什么很重要。術語“靜態分析”是指在不執行程序的情況下分析程序的方法。正如我們將在下一節中看到的，靜態分析工具可用于生成從編碼標準違規到特定錯誤或漏洞的任何報告。簡而言之，靜態分析工具分析源代碼以找到對管理風險有用的信息。

靜態分析的一個好處是它可以在開發周期的早期執行，通常在應用程序執行之前。它通常集成到自動構建中，因此幾乎沒有運行頻繁分析的開銷。通過將靜態分析集成到內部開發循環中，用戶可以最大化他們從此類工具中獲得的價值。

當與精心設計的開發過程結合使用時，靜態分析工具可以提供對軟件狀態的關鍵可見性。這使開發團隊能夠了解其代碼中的風險級別以及風險所在的位置，以便他們可以采取行動來減輕或完全消除它（表 1）。單個工具通常專注于軟件開發團隊面臨的特定問題，團隊經常使用這些工具的組合來全面了解他們的開發工作。

表 1：靜態分析工具通常會發現特定類型的問題，每種類型代表不同類型的風險并需要不同類型的操作。

開發人員傳統上通過簡單的 IDE 集成或作為獨立工具使用靜態分析工具。雖然這些工具為開發工作增加了重要價值，但隨著開發人員花費越來越多的時間使用和維護不同的工具以及篩選越來越多的結果，工具的激增也帶來了效率問題。為了明智地管理開發資源，團隊必須能夠有效地管理、過濾和優先考慮所有這些問題。

為了解決這些問題，開發測試平臺應運而生，以便在一個地方統一和管理所有這些靜態分析信息，從而簡化用戶體驗并在更大范圍內提高可見性和效率，同時提供相關的訪問控制和報告。開發測試平臺甚至開始通過在靜態分析過程中利用早期程序運行期間生成的工件來模糊靜態分析和其他類型分析之間的界限。例如，這些平臺可以在靜態分析期間使用來自測試運行的代碼覆蓋率信息來有效地自動識別缺失的測試用例。解決這個問題的傳統方法需要基于簡單的覆蓋閾值的大量手動工作。通過利用不同來源的數據，

為 Java 選擇靜態分析工具

Java 最流行的免費靜態分析工具可能是 Checkstyle、PMD 和 FindBugs。雖然它們都屬于“靜態分析”的范疇，但它們的優勢是如此不同，以至于許多人認為這些工具是互補的，而不是替代品。

格紋風格

Checkstyle 被稱為“一種開發工具，可幫助程序員編寫符合編碼標準的 Java 代碼 ［1］”，盡管它并不嚴格限制自己執行編碼標準。它為用戶提供了一個文檔化的 API 來定義他們自己的自定義檢查。典型的編碼標準利用基本規則使代碼更具可讀性，并減少未來代碼更改引入錯誤的可能性。標準傾向于定義有關格式（空格、括號、命名、注釋等）、繼承和可見性的約定。如果得到充分執行，設計良好的編碼標準可以幫助開發人員降低風險。但是，執行起來可能很困難，因為編碼標準會產生很多違規行為，并且可能存在忽略嘈雜規則的巨大壓力。使用遺留代碼，這會使執行新的編碼標準變得不可行。雖然 Checkstyle 發現的大多數問題不會影響代碼的正確性、健壯性或性能，但幫助開發人員快速理解其他人編寫的代碼具有真正的價值。如何量化這些違規所代表的風險并不總是顯而易見的，直接從違規計數衡量風險是有問題的，但這些計數的變化可以作為風險變化的合理代理。

PMD

PMD 被描述為“……源代碼分析器。它會發現未使用的變量、空的 catch 塊、不必要的對象創建等等［2］。” 它也在不斷發展，目前的檢查主要集中在可能掩蓋開發人員錯誤的語法異常上，例如過于復雜的表達式、空塊、未使用的變量、參數和類成員。它還有一個流行的模塊來識別重復的代碼。因為它通常報告“可疑代碼”而不是特定的編碼錯誤或違反標準的情況，所以用戶需要仔細選擇為日常使用啟用的檢查。因為強制規則是由用戶選擇的，所以這個工具對遺留項目和新建項目都很有用，而且通常很容易將這些計數與風險相關聯。很遺憾，

查找錯誤

FindBugs 可能是這些工具中最受歡迎的。它查找代碼中的實際錯誤，以及可疑代碼和標準違規。由于報告的問題范圍廣泛，因此使用包含項目最相關檢查的配置非常重要。對于遺留項目尤其如此，因為從一開始就更容易保持新項目的清潔。與 PMD 一樣，任何團隊都可以從使用 FindBugs 中受益，并且將問題計數與風險相關聯非常簡單。

商業靜態分析工具顯示出類似的多樣性，可以識別從標準違規到實際缺陷和安全漏洞的所有內容。為了說明商業工具與免費工具的比較，我使用專有的靜態分析解決方案和 FindBugs 的 2.0.1 版分析了 Jenkins 作業管理系統 （www.jenkins-ci.org） 的 1.496 版，啟用了所有檢查。 在此代碼庫中，識別出 852 個獨特問題——兩種產品僅識別出 28 個問題。該專有解決方案發現了 197 個獨特問題，其中 188 個來自影響較大的類別（安全和并發錯誤、資源泄漏和未處理的異常，如 null 取消引用）。FindBugs 發現了 627 個獨特問題，其中 29 個來自這些高影響類別。簡而言之，

開發測試——將所有內容捆綁在一起

靜態分析工具是 Java 開發人員軟件開發工作中的強大盟友，因為這些工具使開發人員能夠深入了解整個軟件開發生命周期的風險。它們通常很容易自動化，使用戶能夠花時間解決問題而不是運行工具。

在管理風險方面，通常信息越多越好——只要這些信息能夠闡明開發人員關心的實際風險來源。在決定采用哪些工具時，請記住不僅要考慮分析工具識別的問題類型，還要考慮這些工具如何協同工作以提供額外價值。此外，請務必適當地配置它們，以免問題的數量使您的用戶不堪重負。

現代開發測試平臺通過將數據統一在一個地方、簡化用戶體驗并創造機會來提供更多價值，從而將測試工具提升到另一個層次。

審核編輯：郭婷