Sonar 如何看懂Sonar报表

如何看懂 Sonar 報表

Sonar 主要還是透過maven的一些plugins像 PMD , CPD , findbugs , checkstyle , cobertura(coverage ) , JavaNCSS ,… 來對java程式碼做靜態分析(static analysis),然後用比較美觀的方式呈現將各種報表整合在一起。想要看懂Sonar 的分析結果，就得先了解它做了那些方面的分析。 所有相關分析的術語跟分析方式的概要說明在這裡 。

Dashboard

Dashboard看的是統計跟平均值，真正有用的資訊，應該是drilldown進去看到細節會比較有用

Dashboard中常會看到向上或向下的三角型，通常會有灰、紅、綠三色，那個叫Tendency ，是指跟前一次build出來的results比較的結果.

Rules Compliance

左邊的圖是程式五項能力指標

1. Usa. Usability 可用性
2. Eff. Efficiency 效率
3. Mai. Maintainabilitiy 維護性
4. Por. Portability 可攜性
5. Rel. Reliability 可靠性

愈高愈好，最好能五個指標都是 100%

右邊的Voilations是程式經過checkstyle, PDM, findbugs,….這些rule檢查後的不通過數量，嚴重性依上而下為

• Blocker 阻塞
• Critical 嚴重
• Major 主要
• Minor 次要
• Info 資訊

檢查不通過的數量當然是愈少愈好，理想值是都為0

 

建議盡可能的把所有的check rules打開，然後再把不適用的rule做調整或停用

Code coverage

程式的單元測試覆蓋率

• line converage 行覆蓋率 : 100行程式碼，有95被測到，就算95%
• branch coverage 分支覆蓋率 : if - elseif - else 如果只測到if內的code就只有33%，若測到 if - elseif 就是66%，if - elseif - else全測到就是100%
• tests test class數量
• skipped 略過沒測的數量

另外常見的還有

• class converage : 類別覆蓋率
• method converage : 方法覆蓋率

覆蓋率愈高愈好，100%為理想值，但通常，粒度(Grain)的單位愈小，愈難達到100%，粒度的大小由上至下為，類別 > 方法 > 分支 >　行 一般來說，建議值為： 　* class converage 100% 　* method converage 100%

• branch coverage 採用 TDD 的號稱可以達到95%, 但個人建議值在 70% 以上
• line coverage 採用 TDD 的號稱可以達到95%, , 但個人建議值在 80% 以上

覆蓋率比較有爭議性， 覆蓋率 != 品質，但基本上把不需要測試的settor,gettor去掉後，保持line coverage 在75%以上，應該不難。

Complexity

程式的複雜度，採用McCabe 的計算方式

左邊是平均值，右邊的chart圖是統計值，統計有兩個view，可以從class的角度或從method的角度來看(建議)

x軸是複雜度，y軸是數量， 在本例中：

• 複雜度為1的method約有600個
• 複雜度為2的method約有180個
• 複雜度為4的method約有100個
• …

以method為計算單位的建議值

Cyclomatic Complexity Risk Evaluation 中文解釋

1 to 10	a simple program, without very much risk	method夠簡單，風險低
11 to 20	a more complex program, moderate risk	method有點複雜，有點風險
21 to 50	a complex, high risk program	method很複雜，高風險
> 50	an un-testable program (very high risk)	只有上帝跟原開發者才懂的method(也許過個月後，只有剩上帝懂)

Chidamber & Kemerer

左邊的chart圖是LCOM4(Lack of cohesion of methods)，右邊是RFC(Response for class) LCOM4是用來判別類別是否具有太多的責任的指標，一般來說，類別設計應該符合單一責任原則 ,如果一個類別之中的methods，並沒有共同的參數或是公用的field，那表示此類別可能可以進行切割。

LCOM4的說明文章 LCOM4的chart圖x軸是LCOM4的值，y軸是class的數量

• LCOM4 = 1 好的類別，表示類別只有一個責任
• LCOM4 >= 2 可能需進行切割的類別，數字表示可以切割的數量
• LCOM4 = 0 空類別

上圖中，LCOM4=3，每一個區域表示可以被獨立切割的部份

RFC的chart圖x軸是RFC的值，y軸是class的數量，RFC的值愈小愈好，

• 0~50 建議值
• > 50 表示該類別太過複雜

 

這個chart圖，通常會搭配 Dependency Structure Matrix (DSM)

Comments & Duplications

左邊是程式註解的數量，右邊是程式重覆(copy & paste code)的數量

Package design

左邊的Package tangle index是指package糾纏指標，右邊的Dependencies to cut是指有多少個packages需要做依賴性切割

Package tangle index的值愈小愈好

• 0% 最佳值
• 100% 最差值

Dependencies to cut的值愈小愈好，理想值為0

只要圖中消除紅底白色的部份，就可以有效降低Package tangle index

Size metrics

左邊的Lines of code(loc)是程式數量的統計，右邊的classes是類別內容的統計

 

官方资料： http://docs.codehaus.org/display/SONAR/Use+Sonar