如何更好地利用Pmd、Findbugs和CheckStyle分析結果這裡列出了很多Java靜态分析工具，每一種工具關注一個特定的能發揮自己特長的領域，我們可以列舉一下：

Pmd 它是一個基于靜态規則集的Java源碼分析器，它可以識别出潛在的如下問題：

–

可能的bug——空的try/catch/finally/switch塊。

– 無用代碼(Dead

code)：無用的本地變量，方法參數和私有方法。

– 空的if/while語句。

過度複雜的表達式——不必要的if語句，本來可以用while循環但是卻用了for循環。

可優化的代碼：浪費性能的String/StringBuffer的使用。

FindBugs 它用來查找Java代碼中存在的bug。它使用靜态分析方法辨別出Java程式中上百種潛在的不同類型的錯誤。

Checkstyle 它定義了一系列可用的子產品，每一個子產品提供了嚴格程度(強制的，可選的…)可配置的檢查規則。規則可以觸發通知(notification)，警告(warning)和錯誤(error)。

現在有很多檢視這些工具的處理結果的方式：

XML格式：這些工具都可以産生XML檔案，這些XML檔案能用來産生HTML報表或者是被别的工具用來浏覽分析的結果。

HTML格式：HTML格式是最受歡迎的産生報表和團隊間分享的的方式，你也可以用xsl表格建立你自己的報表。

IDE插件：幾乎所有叫得上名字的IDE都給這些工具提供了插件，這使得發現源碼中存在的所有問題幾乎變成可能。

代碼品質工具的一個問題是，它們有時候會給開發者提示很多不是錯誤的錯誤-也叫做假陽性(false

positives)。當這種情況發生的時候，開發者可以學着忽略工具的輸出資訊，或者是把這些輸出全部抛棄掉。

為了更好的利用這些工具的輸出結果，給開發者一個更有用的視圖，最好是有一種隻關注我們想要的東西的方式。本文中，我們将找出其他有趣的方式來更好的利用所有這些有名的Java靜态分析工具的輸出結果，然後可以像查詢資料庫那樣查詢這些結果。

JArchitect和CQLinq

JArchitect是另一個靜态分析工具，它彌補了其他工具(的不足)，它是使用一種基于Linq(CQLinq)的代碼查詢語言像查詢資料庫那樣來查詢代碼。

JArchitect3的以前版本，隻能查詢從JArchitect提取出來的分析資料，但是從JArchitect4開始，可以把許多其他靜态分析工具的輸出結果包含進來，然後使用CQLinq做查詢。

讓我們以PDT核心(的Php插件)的源碼為例來說明如何在JArchitect中利用好這些靜态工具的分析結果。

在查詢分析結果以前，要遵守以下幾個步驟：

第一步：

用PMD，CPD，FindBugs和CheckStyle分析項目工程，生成包含分析結果的XML檔案。

第二步：

用JArchitect分析項目工程。

第三步：

在JArchitect點選菜單“插件(Plugins)”->“導入插件結果檔案(Import Plugins Result

Files)”把所有的XML檔案導入到JArchitect中。

JArchitect預設給這些工具提供了許多有用的查詢，并且這些查詢都是可以很簡單的進行定制的。

讓我們來看一些CQLinq的查詢：

擷取的所有的問題(issue)：

擷取所有問題的請求很簡單，但是沒什麼用處，因為如何利用23272個問題的分析結果确實是一個很大的挑戰。

為了更好的利用這些工具的分析結果，我們可以用CQLinq來做過濾，然後隻關注那些我們想要關注的東西。

根據所使用的檢查工具發請求

我們可以修改第一個請求，然後添加一個查詢工具的criteria。

據規則集發請求

我們也可以根據問題的規則集做過濾：

根據優先級發請求

也可以根據優先級做過濾：

出現次數最多的問題

知道哪些問題是被這些工具報告次數最多的是很有用的。

出現問題最多的類

知道哪些類包含了最多的問題是很有用的。

上圖可以看出來，CheckStyle報告的上千個問題中有很多是可以忽略的。

前面的查詢很有用，但是，它并沒有給我們一個精确的類品質的資訊，因為要考慮的另一個有用的次元就是代碼行數(NBLinesOfCode)。一般來說代碼行數多的類會包含更多的問題，基于這個考慮，我們可以修改之前的請求來計算出問題數目和代碼行數(NBLinesOfCode)的比率。

上面的查詢結果看上去很奇怪，前8個類的問題數和代碼行數比率超過了200，也就是說一行代碼有超過200個問題。

為了解釋這種行為，我們看下CompilerAstParser的一些代碼：

代碼行數(NBLinesOfCode)指的是語句的數目而不是代碼的實體行數，CompilerAstParser這個類聲明了很多數組，每一個都包含了幾千個實體行，但是，每一個數組都被認為是一個語句。

就像前面展示的出現次數最多的問題那樣，每一個數組都把”+應該在一個新行上”這個規則違反了上千次。或許最好是應該把這樣的規則從CheckStyle的配置檔案中删掉。

出問題最多的方法

當靜态警察工具報告了問題以後，定位解決問題的優先級是很有用的，尤其是當包含bug的時候。

bug可能存在于某一個特定的方法中，但是，知道還有多少方法也受這個bug的影響是非常有用的。知道了出問題最多的這個方法做好事盡快把它解決掉。

使用CQLinq，我們可以把這些工具的結果和JArchitect的結果結合起來建立出更複雜的查詢，然後把這些檢查規則添加到建構過程中去。

問題的趨勢

工程中有問題并不是異常情況，我們甚至可以說是正常的，但是，我們要檢查工程的品質趨勢。如果随着工程的更新和演化問題數目增加了，将會是一個很壞的名額。

JArchitect提供了趨勢監控特性來建立趨勢圖。趨勢圖是根據分析時間記錄的特定次元上的值建立出來的。預設有50多個趨勢次元，也可以很簡單定制趨勢次元。

下面給Pmd問題建立一個趨勢次元：

然後，你就可以很簡單的建立趨勢圖在趨勢次元上做監控，然後把它添加到JArchitect的操作面闆中。

有了這個趨勢圖，我們就可以監視Pmd問題的進化，然後發現這個次元的問題随版本進化的原因。

定制JArchitect報表

JArchitect可以在列出了CQLinq查詢的HTML報表中追加額外的報表區。

在CQLinq查詢浏覽面闆中，一個特定的CQLinq組是用橙色的的邊框包圍的。

也可以把Pmd趨勢圖添加到報表中：

在HTML報表中，這些被添加進來的區域可以通過菜單通路：

這是被添加進Pmd查詢報表中的頁面：

結論

JArchitect 4

對其他的靜态分析工具是開放的，你也可以很簡單的像本文說的那樣把你自己的工具做成它的插件。這樣你就可以使用JArchitect的所有的功能來更好的利用那些有名的java靜态分析工具的分析結果。

原文連結：  翻譯： - 

譯文連結：