SonarQube 相關研究

1. 主要功能，如何使用 ?

完整的 Open Source 程式碼品質分析工具，透過 SonarQube 的幫助可以讓我

們程式碼中潛在的問題都一目了然

主要功能有兩種，一種是負責執行程式碼分析的 Runner，每個語言都有自己對

應的 SonarQube Runner （例如 C# 就有 MsBuild Runner），而另外一種則是在

透過 Runner 分析之後，我們可以透過 SonarQube 的報表網站，觀看軟體的健

康檢查報告，了解是否有潛在的技術債（Technical Debt），幫助我們及早發現。

技術債 : 就像經濟上的債務，技術上的債務也是要付利息的，當我們在開

發時，選擇了臨時的應急措施，我們將會付出某種形式的額外代價。

我們可以選擇繼續付利息，或者我們可以選擇通過重構過去的臨時處理方

案，直接支付本金，獲取更好的設計。

2. 品質指標，如何計算 ?

SonarQube 針對程式碼，做了七個指標分析。

分別是不均勻分布的複雜性、潛在的 Bug、有沒有違反程式碼規範、有沒有註

解、程式的設計與架構、有沒有重複的代碼和有沒有單元測試。

圖 1 : 指標分析

技術債計算方式 :

圖 2 : 技術債

把專案中每個 issue 的時間加總，得到的時間。

Issue

在 SonarQube 中，每一個 issue 代表一個不符合程式碼規範的“問題”，有一個

狀態(status)屬性，如果在某一版本的程式碼上出現了一個 issue，後來修改原始

程式碼導致這個 issue 消失，它的狀態就會變為"Close"，但這個 issue 本身不會

消失。

圖 3 : Issue workflow

Issue 依照嚴重程度有五個分類 :

1. BLOCKER :

Bug 有很高的機率會影響整個系統的行為，例如 memory leak，程式碼一定要馬

上修復。

2. CRITICAL :

Empty catch block, SQL injection, ...

3. MAJOR

Quality flaw which can highly impact the developer productivity: uncovered piece of

code, duplicated blocks, unused parameters, ...

4. MINOR

Quality flaw which can slightly impact the developer productivity: lines should not be

too long, "switch" statements should have at least 3 cases, ...

5. INFO

Neither a bug nor a quality flaw, just a finding.

圖 4 : Issue 詳細資料

技術債比率 :

不同的專案中，也許有同樣的技術債，但卻可能有不同的比率。

技術債比率的算法是將技術債除以需要重寫 code 的時間，

SQALE (Software Quality Assessment based on Lifecycle Expectations) : 分數從 A (最

好)到 E (最差)。

圖 5 : SQALE 分數與技術債比率

例如:

有兩個專案有一樣的技術債

專案 A : 95 天、80000 行程式

專案 B : 95 天、7000 行程式

技術債比率公式 : "technical_debt” / "estimated_development_cost”

technical_debt : 轉成分鐘數以及一天工作幾小時

estimated_development_cost : Line of codes * 30 分鐘

專案 A : (95 x 8 x 60) / (80000 x 30) = 1.9%

專案 B : (95 x 8 x 60) / (7000 x 30) = 21.7%

品質指標 :

a. Complexity:

以 Java 為例，當碰到關鍵字複雜度會加一，

例如: if, for, while, case, switch, catch, throw, return, &&. ||

但 else, default, finally 不會增加。

圖 6 : Hello.java 程式

b. Documentation

Comment_lines : 註解行數

Commented-out LOC: 註解的 code

圖 8 : 註解數量的相關數據

圖 7 : Hello.java 的複雜度

c. Duplications

當一個 Java project 至少有 10 行連續的程式碼是一樣的。

圖 10 : 重覆內容程式碼

d. Potential bugs

Bugs 的部分是透過規則得知

例如:沒有關掉 fileReader

圖 9: 檔案重複的行數

e. Architecture and design

新的版本對於結構型的指標已經取消不再使用，

下圖為 5.0 版本 depth in tree 的指標資料，發生在當有繼承行為發生時。

另外在網路上看到一篇 2012 年的 slideshare 介紹關於那時 SonarQube 版本對於

Design 指標的計算方式

資料來源: http://www.slideshare.net/keheliya/sonar-metrics

3. 支援的程式語言

支援超過 25 種程式語言：Java、C、C++、C#、PHP、Flex、Groovy、JavaScript、

Python、SQL、COBOL 等

4. 支援的 Plugins in

Integration : Github、Google Analytics

SCM Engines : CVS 、Git、SVN

External Analysers : Android Lint、PMD

5. 改變規則

一開始專案的 technical debt

圖 11 : 專案更改技術債前的相關數據

Administration -> General settings -> Technical Debt

改變 technical debt 內 LOC 的開發時間和一天工作時數。

圖 12 : 更改技術債頁面

圖 13 : 專案更改技術債後的相關數據

取消規則庫不想要的規則:

圖 14 : Standard output should not be used directly to log anything 規則

紅框部分為所有專案中，有違反此規則的專案和數量。

我們可以自行定義此規則的嚴重程度、增加規則相關說明、要不要取消此規

則。

6. 流程圖

流程圖說明:

A-1: Eclipse 安裝 SonarLint plugin

A-2: 設定 SonarQube server、選擇要上傳到哪個專案、將資料上傳進行分析。

B-1: 本機端下載 SonarQube Scanner，並在 Eclipse 新增 sonar-

project.properties 檔案設定專案名稱及 key

B-2: 在專案位置打開 Command line，執行 sonar-scanner，將專案上傳進行分

析。

C-1: 將 Eclipse 的專案傳到遠端 git server

C-2: Jenkins 拿 git server 的檔案

C-3: 在 Jenkins 安裝 SonarQube Scanner plugins ，並設定 SonarQube server 位

址，專案名稱及 key

C-2: 建置專案，專案上傳 SonarQube 進行分析。

SonarQube

Scanner

Scanner Plugin

A-1 A-2

B-1 B-2

C-1

C-2 C-3

C-4

7. 透過本機端啟動 SonarQube

a. 下載 SonarQube

安裝版本: 5.6

StartSonar.bat 啟動 localhost

b. Eclipse 安裝 SonarLint 套件

安裝版本: 2.3.1

需求必須是 Java 8 & SonarQube 5.6+

c. 下載 SonarScanner

安裝版本: 2.6

設定環境變數到/bin

d. Eclipse 設定 SonarQube 相關 Console

把 SonarLint 相關東西加進來 window -> show view -> other -> SonarLint

e. 設定 SonarQube server

f. 在 Eclipse 執行一次分析

檔案按右鍵 -> SonarLint -> Analyze

分析結果

g. 將分析結果丟到 SonarQube

參考文件:

http://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Scanner

https://www.youtube.com/watch?v=Gu9skLzRSao

新增 sonar-project.properties 在專案的第一層

設定要的 projectKey & Name

在檔案路徑打開終端機 -> 輸入 sonar-scanner 將此 project 丟到 SonarQube

若是兩個專案有一樣的 key 值，則第二個會覆蓋第一個

若兩個專案不同 key 值，但有一樣的專案名稱，會視為兩個不同專案。

注意這裡的 java 版本必須為 8，若是 7 會出現錯誤

若是 SonarQube 不存在此 projectName 會新增一個

存在則會更新。

8. 透過 Jenkins 更新 SonarQube

a. Jenkins 設定 SonarQube 等設定

IP

Scanner

針對專案建置專案名稱及 key

b. Eclipse 專案丟到 Git Server，在透過 Jenkins 更新 SonarQube

Jenkins Output

11. 取得 Coverage 報表資料

若要取得 coverage 的資料必須透過 Jacoco，而 Jacoco 要透過 Gradle 才能使用

步驟如下

a. 在 Eclipse 的專案中，對 build.gradle 做修改

讓 gradle 建置時可以取得 SonarQube plugins，並設定 SonarQube 的專案名稱

和 key。

b. 執行 gradle sonarqube

專案 -> Run as -> gradle build

此步驟會將我們的專案傳到 SonarQube server 進行分析

(等同於 sonar-scanner 的功能)

c. 得到 Coverage 資料

單元測試失敗

12. PMD 與 SonarQube

a. PMD 簡介 :

靜態程式碼分析，找尋潛在問題，如

疑似臭蟲的程式碼(Possible bugs)，如空的 try/catch/finally/switch 語句。

無法執行的程式碼(Dead code)，如未使用的區域變數、參數、私有函數。

不佳的程式碼(Suboptimal code)，如 String/StringBuffer 的不良使用方式。

過度複雜的語法(Overcomplicated expressions)，如不必要的「if」語句或可用「while」

迴圈取代「for」迴圈。

重複程式碼(Duplicate code)，如透過複製/貼上有可能連臭蟲程式碼也複製了。

b. 安裝 PMD plugin

Administration -> System -> Update Center

安裝後，重新啟動 server

c. 啟動 PMD 規則

新增一個 Quality Profile

選擇要使用此 Quality Profile 分析的專案

這時，此 Quality Profile 還沒有任何規則

進入 rule 頁面 -> 點選 active PMD ，並選擇要啟動的規則

選完之後，按 Bulk change -> activate in PMD (java)

產生了 6 六百多條規則 (sonarqube 與 PMD 規則)

d. 重新 Scanner 一次

e. 從資料庫裡觀看規則

可以看到每個規則屬於源自於哪一種 plugins