Table of contents


如何看懂 Sonar 報表

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

Dashboard

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

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

Rules Compliance

sonar_101_001.png

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

  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

sonar_101_002.png

程式的單元測試覆蓋率

  • 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

sonar_101_003.png

程式的複雜度,採用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

sonar_101_004.png

左邊的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 空類別

sonar_101_008.png

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

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

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

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

Comments & Duplications

sonar_101_005.png

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

Package design

sonar_101_006.png

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

Package tangle index的值愈小愈好

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

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

sonar_101_009.jpg

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

Size metrics

sonar_101_007.png

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

Jacoco Coverage report

用maven產生 jacoco coverage report

pom.xml

            <plugin>
                <groupId>org.jacoco</groupId>
                <artifactId>jacoco-maven-plugin</artifactId>
                <version>0.7.5.201505241946</version>
                <executions>
                    <execution>
                        <goals>
                            <goal>prepare-agent</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>

執行以下指令後,就會在sonarqube產生 coverage report

mvn org.jacoco:jacoco-maven-plugin:prepare-agent clean install -Pcoverage-per-test sonar:sonar -Dsonar.host.url="http:/localhost:9000"

Resources