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

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

靜態(tài)分析有助于降低風險

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

靜態(tài)分析的一個好處是它可以在開發(fā)周期的早期執(zhí)行，通常在應(yīng)用程序執(zhí)行之前。它通常集成到自動構(gòu)建中，因此幾乎沒有運行頻繁分析的開銷。通過將靜態(tài)分析集成到內(nèi)部開發(fā)循環(huán)中，用戶可以最大化他們從此類工具中獲得的價值。

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

表 1：靜態(tài)分析工具通常會發(fā)現(xiàn)特定類型的問題，每種類型代表不同類型的風險并需要不同類型的操作。

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

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

為 Java 選擇靜態(tài)分析工具

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

格紋風格

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

PMD

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

查找錯誤

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

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

開發(fā)測試——將所有內(nèi)容捆綁在一起

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

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

現(xiàn)代開發(fā)測試平臺通過將數(shù)據(jù)統(tǒng)一在一個地方、簡化用戶體驗并創(chuàng)造機會來提供更多價值，從而將測試工具提升到另一個層次。

審核編輯：郭婷