掌握品質：SonarQube 與實務應用

身為一個在軟體開發領域浸淫多年的技術工作者，我深刻體認到程式碼品質對軟體專案成敗的關鍵影響。程式碼品質不佳，猶如埋下不定時炸彈，輕則增加維護成本，重則導致系統當機。因此，如何有效管理和提升程式碼品質，一直是開發團隊的首要任務。在眾多程式碼品質管理工具中，SonarQube 以其全面的分析能力和易於使用的介面脫穎而出，成為我推薦給開發團隊的最佳選擇。

SonarQube 就像一位經驗豐富的程式碼醫生，能全面診斷程式碼的健康狀況，從錯誤、漏洞到程式碼異味，都能精準識別。更重要的是，它不僅能指出問題所在，還能提供具體的改進建議，幫助開發團隊寫出更乾淨、更健壯的程式碼。

SonarQube 七大維度：全方位程式碼體檢

SonarQube 從七個維度對程式碼進行全方位分析，涵蓋了程式碼品質的各個導向：

程式碼錯誤 (Bugs)： 找出潛在的程式碼錯誤，例如空指標例外、資源洩漏等，將程式碼錯誤扼殺在搖籃中。
程式碼異味 (Code Smells)： 識別不符合最佳實踐的程式碼，例如過長的方法、過多的引數等，提升程式碼的可讀性和可維護性。
漏洞 (Vulnerabilities)： 揪出程式碼中潛藏的安全漏洞，例如 SQL 注入、跨站指令碼攻擊等，防範資安風險。
程式碼重複度 (Duplications)： 找出重複的程式碼片段，建議進行重構，減少程式碼冗餘，降低維護成本。
測試覆寫率 (Test Coverage)： 統計測試覆寫率，找出未被測試覆寫的程式碼，確保程式碼的測試完整性。
程式碼複雜度 (Complexity)： 計算程式碼的複雜度，建議進行簡化，降低程式碼的理解和維護難度。
程式碼規範 (Coding Standards)： 支援多種程式碼規範，例如 Java 的 Checkstyle、PMD 等，幫助團隊統一程式碼風格，提升團隊協作效率。

  graph LR
    subgraph "SonarQube 七大維度"
        A[SonarQube] --> B(錯誤)
        A --> C(異味)
        A --> D(漏洞)
        A --> E(重複度)
        A --> F(測試覆寫率)
        A --> G(複雜度)
        A --> H(程式碼規範)
    end

圖表說明： SonarQube 從七個維度全方位分析程式碼品質。

SonarQube 實戰：整合 CI/CD 流程

我曾在一個大型專案中匯入 SonarQube，並將其整合到 CI/CD 流程中。每次程式碼提交後，系統會自動觸發 SonarQube 分析，並將分析結果回饋給開發團隊。這讓我們能夠及時發現和修復程式碼問題，有效防止技術債務累積。

sonar-scanner \
  -Dsonar.projectKey=my-project \
  -Dsonar.sources=. \
  -Dsonar.host.url=http://localhost:9000 \
  -Dsonar.login=my-token

這段程式碼示範瞭如何使用 sonar-scanner 命令執行 SonarQube 分析。sonar.projectKey 指定專案金鑰，sonar.sources 指定程式碼目錄，sonar.host.url 指定 SonarQube 伺服器地址，sonar.login 指定登入權杖。

SonarQube 的價值：提升程式碼品質，降低技術債務

我認為 SonarQube 是每個開發團隊都應該擁有的程式碼品質管理利器。它不僅能幫助我們提升程式碼品質，還能減少技術債務，提升開發效率，最終交付更健壯、更可靠的軟體。

軟體品質的雙重導向：內在與外在的平衡

軟體品質包含內在和外在兩個導向。外在品質著重於軟體是否滿足功能需求，而內在品質則關注軟體設計和實作的優良程度，例如可維護性和可修改性。我發現，業界普遍認為 80% 的軟體成本花費在維護上，而內在品質對維護成本的影響至關重要。

  graph LR
    D[D]
    E[E]
    A[軟體品質] --> B(外在品質)
    A --> C(內在品質)
    B --> D{滿足功能需求?}
    C --> E{易於修改和維護?}
    E --> F[影響軟體未來成本]

圖表說明： 軟體品質包含內在和外在兩個導向，其中內在品質對軟體未來成本影響重大。

持續檢測是現代軟體開發的趨勢，它強調在整個開發過程中持續關注程式碼品質，並縮短回饋週期，以便及時發現和解決問題。SonarQube 正是實作持續檢測的理想工具。

  graph LR
    C[C]
    D[D]
    A[持續檢測] --> B{開發團隊掌控品質}
    A --> C{縮短回饋週期}
    A --> D{持續管理技術債務}
    D --> E[SonarQube]

圖表說明： 持續檢測強調在開發過程中持續關注程式碼品質，SonarQube 是實作持續檢測的有效工具。

認識 SonarQube：程式碼品質管理的利器

在軟體開發的過程中，我們常常自問：「我們的程式碼寫得好嗎？」過去，這個問題的答案往往流於表面，例如「可以編譯」、「看起來能動」、「使用者沒抱怨」。然而，這樣的答案並不足以確保軟體的長期健康發展，直到使用者開始抱怨，或是需要新增功能時，我們才意識到程式碼的潛在問題。

SonarQube，一個免費與開源的程式碼品質平台，正是為瞭解決這個問題而生的。它提供程式碼品質的即時快照，以及落後（已發生問題）和領先（潛在問題）品質指標的趨勢分析。例如，測試覆寫率（領先指標）若只有 50%，或許不算理想，但如果上個月只有 35%，就代表有所進步；反之，若從 70% 下降，則需積極改善。

SonarQube 不僅能指出問題所在，更提供 IDE 整合、持續整合伺服器（如 Jenkins）整合以及程式碼審查工具等品質管理工具，協助您有效修正問題。相較於其他商業競爭對手，SonarQube 更涵蓋了「七大品質導向」：程式碼規則、測試覆寫率、重複程式碼、API 檔案、程式碼複雜度、架構以及錯誤。這樣的廣度讓 SonarQube 能更全面地評估程式碼品質。

  graph LR
    D[D]
    E[E]
    A[軟體品質] --> B(外部品質)
    A --> C(內部品質)
    B --> D{測試}
    C --> E{SonarQube}

    style E fill:#ccf,stroke:#888,stroke-width:2px

此圖表闡述軟體品質的雙重導向：外部品質和內部品質。測試著重於外部品質，驗證軟體功能是否符合預期；而 SonarQube 則關注內部品質，分析程式碼的結構、風格和潛在問題，確保軟體的可維護性和擴充套件性。

  graph LR
    A[SonarQube] --> B(錯誤)
    A --> C(程式碼規則)
    A --> D(測試覆寫率)
    A --> E(重複程式碼)
    A --> F(API 檔案)
    A --> G(程式碼複雜度)
    A --> H(架構)

此圖表展示 SonarQube 的七大品質導向，涵蓋程式碼的各個導向，從程式碼風格、錯誤檢測到架構分析，提供全面的程式碼品質評估。

技術深度提升：SonarQube 的技術優勢

或許您會問，既然 SonarQube 使用現有工具，為何還需要它？直接使用這些工具不行嗎？我認為有幾個主要原因。首先，這些工具產生的只是一堆積潛在問題清單，缺乏量化的指標和趨勢分析，難以追蹤程式碼品質的變化。

再者，即使不透過 SonarQube，這些工具也能獨立運作，但實際上，開發者真的會規律地使用它們嗎？使用的設定是否一致？品質報告的透明度又如何？SonarQube 透過標準化的規則集，解決了這些問題，不僅能針對特定專案進行重複分析，還能涵蓋所有專案，確保程式碼品質的一致性。

此外，SonarQube 也提供獨有的規則和演算法，例如增強的重複程式碼檢測機制，可以跨專案找出複製貼上的程式碼。儘管功能強大，SonarQube 的操作卻相當簡便。直觀的介面、簡易的分析設定，加上與 IDE 和程式碼審查工具的整合，讓開發者能輕鬆上手，並有效管理程式碼品質。

多語言支援與本地化

(待續，後續將探討 SonarQube 的多語言支援、本地化以及實務應用等主題)

軟體架構的七個評估導向：開發穩固的軟體根本

軟體架構如同建築藍圖，決定了系統的成敗。它不僅影響開發效率，更決定了系統的長期可維護性、可擴充性和穩定性。我將分享多年經驗總結的七個軟體架構評估導向，並搭配實務案例與圖表，助您開發高品質、易維護的軟體系統。

1. 模組化：解耦合的藝術

我認為，良好的軟體架構應該像樂高積木一樣，由獨立的模組組成。每個模組負責單一功能，模組之間的耦合度低，修改一個模組不會影響其他模組。這能大幅提升系統的可維護性和可測試性。

  graph LR
    A[模組 A] --> B[模組 B]
    C[模組 C] --> B
    B --> D[輸出]

模組 A 和 C 獨立運作，透過定義良好的介面與模組 B 互動，最終產生輸出 D。這種解耦合的設計，讓修改模組 A 或 C 時，不會影響模組 B 和 D。

2. 抽象化：化繁為簡的力量

抽象化是將複雜系統簡化的利器。它隱藏了底層的實作細節，提供簡潔的介面給上層使用。例如，資料函式庫連線的抽象層可以遮蔽不同資料函式庫的差異，讓應用程式碼無需關心底層的資料函式庫型別。

3. 可擴充性：應對未來變化的能力

系統需求總是不斷變化，可擴充性是應對未來變化的關鍵。我設計系統時，會考慮如何應對流量增長、功能擴充套件等需求。例如，採用微服務架構可以將系統拆分成小型服務，每個服務可以獨立擴充套件。

4. 可維護性：降低維護成本的關鍵

可維護性是評估軟體架構的重要指標。程式碼應該易於理解、修改和除錯。我經常使用設計模式和程式碼重構技巧來提升程式碼的可維護性。

5. 可靠性：確保系統穩定運作

可靠性是指系統在預期時間內正常運作的能力。我設計系統時，會考慮容錯機制、錯誤處理和日誌記錄等方面，確保系統的穩定性。

6. 效能：速度與效率的追求

效能是使用者經驗的關鍵。我設計系統時，會考慮程式碼的執行效率、資料函式庫的查詢效能和網路的延遲等因素，確保系統的快速回應。

7. 安全性：保護系統免受威脅

安全性是軟體開發中不可忽視的一環。我設計系統時，會考慮如何防止 SQL 注入、跨站指令碼攻擊等安全漏洞，保護系統和使用者資料的安全。

  classDiagram
    class 軟體架構 {
        +模組化
        +抽象化
        +可擴充性
        +可維護性
        +可靠性
        +效能
        +安全性
    }

此圖表展示了軟體架構的七個關鍵導向，它們共同構成了一個穩固的軟體架構。

透過以上七個導向的評估，我們可以更全面地理解軟體架構的品質，並有針對性地進行最佳化，最終開發出高品質、易維護的軟體系統。在我的實務經驗中，我發現這些導向相互影響，需要權衡取捨，才能找到最佳的架構方案。


在軟體開發的過程中，程式碼品質往往是決定專案成敗的關鍵因素。我認為，一套有效的程式碼品質管理系統，不僅能幫助團隊及早發現並解決潛在問題，還能降低技術債務，提升軟體的可維護性和可擴充套件性。本文將以 SonarQube 為例，深入剖析軟體品質議題與程式碼規範，並分享我在實務中的一些經驗和心得。

## SonarQube 介面導覽與鑽取式分析

SonarQube 提供了直觀的介面，讓我們能以鑽取式分析 (Drilldowns) 的方式，由專案整體逐步深入至個別檔案的程式碼品質。儀錶板頂端會顯示所選指標及其數值，下方則依序呈現模組、目錄/套件，以及類別/檔案等階層式的小工具。

```mermaid
graph LR
A[專案指標] --> B(模組)
B --> C(目錄/套件)
C --> D(檔案)

此圖表展示 SonarQube 鑽取式分析的階層結構，從專案整體指標開始，逐步細化至模組、套件，最終聚焦於個別程式碼檔案，幫助我們快速鎖定程式碼品質的瓶頸。

點選檔案名稱即可檢視檔案細節，包含完整檔案名稱和一系列類別似標籤頁的連結，例如程式碼重複率、複雜度等。SonarQube 會清楚標示需要關注的程式碼片段，方便我們判斷程式碼的健康狀況。

此外，趨勢箭頭以紅、綠、灰三色分別表示指標變差、變好和無變化，顯示 30 天的趨勢，讓我們能掌握程式碼品質的變化趨勢。

技術債務與 Views 外掛應用

技術債務指的是因程式碼品質問題而產生的額外修改成本。SonarQube 的技術債務外掛能以美元和人天為單位量化技術債務，其數值來自問題數量、程式碼重複率、未註解的 API 比例等指標。

  graph LR
    B[B]
    C[C]
A[技術債務] --> B{美元};
A --> C{人天};
B --> D(問題數量);
B --> E(程式碼重複率);
B --> F(未註解API比例);

此圖表說明技術債務的計算方式，它將問題數量、程式碼重複率等指標轉換為實際的成本，以美元和人天呈現，讓技術債務的概念更易於理解和管理。

Views 外掛則提供跨專案的彙總資訊，讓管理者能快速掌握多個專案或團隊的程式碼品質指標，避免手動更新試算表，提升效率並減少錯誤。

深入解析潛在 Bug 與編碼規則

SonarQube 將程式碼中的反模式歸類別為「議題」，涵蓋潛在 Bug 和編碼規則兩個導向。議題小工具會顯示專案的規則遵循指數，並依嚴重性分類別議題。

  graph LR
    C[C]
    D[D]
    E[E]
    F[F]
    G[G]
    A[議題總數] --> B(嚴重性);
    B --> C{阻礙性};
    B --> D{嚴重};
    B --> E{主要};
    B --> F{次要};
    B --> G{提示};
    A --> H[規則遵循指數];

此圖表展示議題小工具的資訊架構，包含議題總數、嚴重性分類別以及規則遵循指數，提供程式碼品質的整體概況。

透過議題深入分析，我們可以進一步檢視每個議題的細節，包含嚴重性、規則、套件、類別/檔案等資訊，並使用篩選功能快速定位問題程式碼。

  graph LR
    C[C]
    D[D]
    E[E]
    A[嚴重性] --> B(規則);
    B --> C{規則1};
    B --> D{規則2};
    B --> E{規則3};
    C --> F[套件];
    D --> F;
    E --> F;
    F --> G[類別/檔案];

此圖表說明議題深入分析的層次結構，從嚴重性和規則開始，逐步細化至套件和類別/檔案，幫助我們精確找出問題所在。

在檔案細節檢視中，我們可以透過「所有錯誤」下拉選單，篩選特定嚴重性或規則的錯誤，更有效率地進行程式碼健檢。

  graph LR
A[點選檔案] --> B{顯示檔案錯誤};
B -- 已篩選清單 --> C[特定規則錯誤];
B -- 未篩選清單 --> C;
C --> D[所有錯誤下拉選單];
D -- 嚴重性 --> E[特定嚴重性錯誤];
D -- 規則 --> F[特定規則錯誤];

此圖表展示檔案細節檢視中「所有錯誤」下拉選單的功能，可以依嚴重性或規則篩選錯誤，方便我們專注於特定型別的問題。

我認為，善用 SonarQube 的介面和功能，搭配程式碼規範的制定和執行，能有效提升軟體品質，降低技術債務，並建立更健壯、更易維護的程式碼函式庫。

玄貓解讀程式碼品質：從潛在問題到效能最佳化

身為台灣技術工作者，我經常強調程式碼品質的重要性。程式碼就像建築的根本，穩固的根本才能撐起宏偉的建築。程式碼中潛藏的問題就像地基的裂縫，即使一開始不明顯，也可能隨著時間推移而擴大，最終導致整個系統崩塌。這篇文章將探討程式碼中常見的幾種問題，並分享我多年來的經驗和洞見。

程式碼異狀：警示燈號

SonarQube 是一款優秀的程式碼品質管理工具，它能幫助我們找出程式碼中潛在的問題。我發現 SonarQube 標記問題的方式相當巧妙，它並非單純指出錯誤，而是像一位經驗豐富的醫生，能從一些細微的症狀中發現潛在的疾病。例如，空的條件式區塊：

public void complexMethod(RequestObject request) {
    String day = request.getWeekday();
    if (day.equals("Tuesday")) {
        // 什麼都沒做
    }
}

這段程式碼看起來人畜無害，但卻隱藏著一個問題：if 條件式區塊是空的。這就像設定了一個鬧鐘，卻沒有設定任何提醒動作。這種情況通常表示開發者可能忘記實作某些邏輯，或者在重構過程中不小心刪除了程式碼。雖然不會立即造成錯誤，卻可能埋下日後出錯的種子。

另一個值得注意的異狀是過多的 null 檢查。適當的 null 檢查能避免程式當機，但過多的檢查就像過度用藥，反而會降低程式碼的可讀性和效能。當我看到程式碼中充斥著 null 檢查時，我會仔細檢查程式碼的邏輯，看看是否有更好的方式來處理 null 值。

錯誤的溫床：程式碼陷阱

有些程式碼問題不會立即引發錯誤，但卻可能在未來造成麻煩。例如，省略大括號的條件式陳述式：

if (day.equals("Saturday") || day.equals("Sunday"))
    playLotto();
    sleepLate();

這段程式碼的意圖是在週末玩樂透並睡懶覺。但由於省略了大括號，只有 playLotto() 會在條件成立時執行，而 sleepLate() 則會每天都執行。這就像設定了一個只在週末響鈴的鬧鐘，卻不小心把「每天睡懶覺」的功能也開啟了。這種寫法容易造成誤解，尤其在團隊協作中，其他開發者可能沒有注意到這個細節，導致修改程式碼時引入錯誤。

不規範的命名也是一個容易被忽視的問題。我認為程式碼的可讀性就像文章的通順度，清晰的命名能讓程式碼更容易理解和維護。不規範的命名就像一篇充滿錯別字的文章，讓人看得頭昏眼花。

效能殺手：程式碼瓶頸

有些程式碼問題不會影響程式的正確性，但卻會影響效能。例如，在 Java 中，不恰當的字串操作會導致效能下降。在迴圈中使用 += 拼接字串就是一個典型的例子。

String result = "";
for (int i = 0; i < 1000; i++) {
    result += i;
}

在迴圈中使用 += 拼接字串會不斷建立新的字串物件，造成記憶體的浪費和效能的損耗。我建議使用 StringBuilder 或 StringBuffer 來進行字串拼接，它們能有效避免這個問題。

其他影響效能的因素還包括不必要的 import 宣告、不恰當的數學物件使用等。這些問題就像水管中的雜質，會阻礙資料的流動，降低程式的執行效率。

程式碼風格：團隊的共同語言

程式碼風格一致性就像團隊的共同語言，它能提高團隊的溝通效率和協作能力。一致的程式碼風格能讓開發者更容易理解彼此的程式碼，減少程式碼審查的時間，提高開發效率。

if (day.equals("Monday")) {
    // ...
}

if (day.equals("Monday")) {
    // ...
}

以上兩個程式碼片段的功能相同，但風格略有不同。我個人比較偏好第二種風格，因為它在括號前後都加了空格，看起來更清晰易讀。在團隊開發中，應該統一程式碼風格，就像制定交通規則一樣，讓程式碼的道路更加暢通無阻。

系統架構圖

  graph LR
    B[B]
    C[C]
    No[No]
    Yes[Yes]
    A[RequestObject] --> B{getWeekday()}
    B --> C{day.equals("Tuesday")}
    C -- Yes --> D[執行商業邏輯]
    C -- No --> E[結束]

圖表說明： 此流程圖展示了 complexMethod 方法的執行流程。首先，從 RequestObject 物件取得星期幾，然後判斷是否為星期二。如果是，則執行對應的商業邏輯；否則，方法結束。

SonarQube 規則：品質的守護者

SonarQube 的規則就像程式碼品質的守護者，它們能幫助我們找出程式碼中潛在的問題。這些規則來自於業界的最佳實務和經驗教訓，涵蓋了程式碼的各個方面，從程式碼風格到潛在的錯誤。

SonarQube 提供了多種規則設定檔，可以根據專案的需求選擇不同的設定檔。我建議使用包含 FindBugs 規則的設定檔，因為 FindBugs 能對編譯後的位元組碼進行靜態分析，找出更深層次的程式碼問題。

程式碼品質是軟體開發的根本。從潛在的錯誤到效能問題，再到程式碼風格，每個細節都可能影響專案的成敗。透過使用程式碼分析工具如 SonarQube，並遵循最佳實務，我們可以有效地提高程式碼品質，降低開發成本，提升專案的成功率。

身為台灣技術工作者，我經常強調軟體品質的重要性，而單元測試正是確保程式碼功能正確的根本。評估單元測試的有效性，不能只看測試成功率，測試失敗、錯誤的數量以及跳過的測試同樣關鍵。任何非零的失敗或錯誤數量都值得關注，它可能暗示程式碼中潛藏的錯誤，或是單元測試本身需要更新。跳過的測試雖然不如失敗的測試嚴重，但也需要深入調查，找出測試被跳過的原因，例如是否有過時的測試案例，或是開發者刻意忽略了失敗的測試。

我發現，許多開發者容易陷入一個迷思，認為單元測試只是為了追求高覆寫率。然而，覆寫率只是其中一個導向，更重要的是測試的品質和有效性。一個覆寫率很高的測試套件，如果測試案例設計不佳，仍然可能無法發現程式碼中的缺陷。

單元測試指標：全面解讀

以下表格列出了幾個重要的單元測試指標，並結合我個人的經驗進行解讀：

指標	說明	玄貓的見解
失敗數	斷言失敗的絕對數量。	這個數字必須為零。任何失敗的測試都代表潛在的程式碼錯誤，需要立即修復。
錯誤數	發生錯誤的測試的絕對數量。	同樣地，錯誤數也必須為零。錯誤通常是由未處理的異常引起的，需要仔細檢查程式碼邏輯。
測試數	執行的測試總數。	測試數量本身並不代表程式碼品質，但可以作為一個參考值，評估測試的完整性。
跳過數	未執行的測試的絕對數量。	跳過的測試需要特別關注。務必找出跳過的原因，並決定是否需要重新啟用或移除這些測試。
執行時間 (毫秒)	執行所有測試所需的時間。	過長的執行時間會影響持續整合的效率。我建議定期檢視測試效能，並進行最佳化。
單元測試成功密度	單元測試套件在上次執行中的整體成功率。	這個指標應該維持在 100%。任何低於 100% 的數值都代表測試存在問題。

  graph LR
    B[B]
    C[C]
    D[D]
    E[E]
    F[F]
A[單元測試] --> B{失敗數}
A --> C{錯誤數}
A --> D{跳過數}
A --> E{測試數}
A --> F{執行時間}
B --> G(程式碼品質)
C --> G
D --> G
E --> G
F --> G

圖表說明： 此圖表展示了各個單元測試指標與程式碼品質之間的關係。所有指標都會影響最終的程式碼品質。

程式碼範例與深度解析

以下提供一個程式碼範例以及我的深度解析：

public class NumberUtils {
    public static int add(int a, int b) {
        return a + b;
    }

    public static int subtract(int a, int b) {
        return a - b;
    }
}

這段程式碼定義了一個名為 NumberUtils 的工具類別，包含 add 和 subtract 兩個靜態方法，分別用於執行加法和減法運算。使用靜態方法的好處是可以直接透過類別名稱呼叫，無需建立物件實體。然而，這種設計也限制了擴充性，例如無法透過繼承或介面多型來修改方法的行為。

在設計工具類別時，我通常會考慮使用介面和工廠模式，以提高程式碼的彈性和可維護性。例如，可以定義一個 Calculator 介面，包含 add 和 subtract 方法，然後實作不同的 Calculator 類別，例如 BasicCalculator 和 ScientificCalculator。這樣可以根據不同的需求選擇不同的計算器實作，而無需修改 NumberUtils 類別的程式碼。

  sequenceDiagram
    participant Client
    participant NumberUtils

    Client->>NumberUtils: add(2, 3)
    activate NumberUtils
    NumberUtils-->>Client: 5
    deactivate NumberUtils

    Client->>NumberUtils: subtract(5, 2)
    activate NumberUtils
    NumberUtils-->>Client: 3
    deactivate NumberUtils

圖表說明： 此序列圖展示了客戶端如何使用 NumberUtils 類別的 add 和 subtract 方法。

技術取捨

在選擇單元測試框架時，JUnit 和 TestNG 是兩個常見的選項。JUnit 歷史悠久，社群龐大，使用廣泛。TestNG 則提供了更豐富的功能，例如註解、引數化測試和測試分組。我個人更偏好 TestNG，因為它更靈活，更能滿足複雜的測試需求。

隨著人工智慧和機器學習的發展，自動化測試技術也將不斷進化。我相信，未來單元測試將更加智慧化，能夠自動生成測試案例、自動偵測程式碼缺陷，並提供更精確的測試報告。

我認為，持續學習和精進測試技能對於每位開發者都至關重要。只有不斷地學習新的技術和方法，才能在快速變化的軟體開發領域保持競爭力。

在軟體開發的旅程中，程式碼品質如同根本，而測試則是確保根本穩固的關鍵。我認為，僅憑程式碼審查難以全面評估測試的完整性，因此，程式碼覆寫率便成為衡量測試有效性的重要指標。本文將探討程式碼覆寫率的意義與侷限性，並結合 SonarQube 工具，分享如何分析程式碼覆寫率，並提升單元測試程式碼的品質。

程式碼覆寫率的多導向解讀

程式碼覆寫率並非單一指標，它涵蓋了行覆寫率、分支覆寫率和程式碼覆寫率等多個導向。行覆寫率指的是被測試執行到的程式碼行數比例，而分支覆寫率則關注程式碼中不同分支路徑的覆寫情況。程式碼覆寫率則是結合了行覆寫率和分支覆寫率的綜合指標。

追求高覆寫率固然重要，但切勿盲目追求 100% 覆寫率。我曾遇到過一個案例，即使程式碼覆寫率達到了 100%，仍然存在邊界條件未被測試到的問題。這提醒我們，測試案例的設計才是關鍵，必須涵蓋各種邊界值和特殊情況，才能真正提升軟體的可靠性。

SonarQube：程式碼品質的守護者

SonarQube 作為一款強大的程式碼品質管理工具，提供了程式碼覆寫率分析、單元測試程式碼品質評估等功能。它能幫助我們快速找出測試覆寫率不足的程式碼區域，並提供詳細的測試報告。

以下圖表展示了 SonarQube Coverage 頁籤的功能：

  graph LR
    E[E]
A[Coverage 頁籤] --> B(檔案名稱)
A --> C(程式碼覆寫率指標：行/分支/程式碼)
A --> D(原始碼)
D --> E{顯示選項}
E -- 需覆寫的行 --> F(顯示需覆寫的程式碼行)
E -- 未覆寫的行 --> G(顯示未覆寫的程式碼行)
E -- 需覆寫的分支 --> H(顯示需覆寫的分支)
E -- 未覆寫的分支 --> I(顯示未覆寫的分支)

SonarQube 提供多種顯示選項，例如「未覆寫的行」和「未覆寫的分支」，可以幫助我們快速定位需要加強測試的程式碼區域。此外，SonarQube 還能顯示每一行被測試執行的次數以及分支覆寫情況，讓我們更精確地掌握程式碼的測試狀況。

單元測試程式碼品質的提升之道

SonarQube 不僅能分析程式碼覆寫率，還能評估單元測試程式碼的品質。透過 Unit Test Success 指標，我們可以檢視測試檔案、測試方法的執行時間和狀態，例如成功、跳過、錯誤和失敗。

我認為，高品質的單元測試程式碼應該具備以下特性：

簡潔易懂： 測試程式碼應該簡潔明瞭，易於理解和維護。
針對性強： 每個測試案例應該只測試一個特定的功能或行為。
斷言明確： 使用清晰的斷言來驗證測試結果。
覆寫全面： 儘可能覆寫各種邊界值和特殊情況。

以下是一個使用 JUnit 測試 isAdult 方法的範例：

import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.*;

public class AgeValidationTest {

    @Test
    public void testIsAdult_validAge() {
        Employee employee = new Employee();
        assertTrue(employee.isAdult(18));
    }

    @Test
    public void testIsAdult_invalidAge() {
        Employee employee = new Employee();
        assertFalse(employee.isAdult(17));
    }
}

這段程式碼使用 JUnit 框架進行單元測試。testIsAdult_validAge 方法測試了年齡為 18 歲的情況，預期 isAdult 方法傳回 true。testIsAdult_invalidAge 方法測試了年齡為 17 歲的情況，預期 isAdult 方法傳回 false。

從程式碼覆寫率到測試策略的制定

程式碼覆寫率只是測試策略的一部分，我們還需要結合其他指標和方法，例如程式碼複雜度、程式碼異味等，才能制定更完善的測試策略。我建議，在專案開發過程中，應定期監控程式碼覆寫率的變化趨勢，並設定合理的覆寫率目標，持續提升軟體的品質和可靠性。

透過本文的分享，希望能幫助您更深入地理解程式碼覆寫率的意義，並結合 SonarQube 等工具，開發更健壯的軟體。

在軟體開發的過程中，確保程式碼品質至關重要。除了單元測試，整合測試更是不可或缺的一環，它驗證了不同模組之間的互動作用是否符合預期，確保整個系統的穩定性和可靠性。本文將探討如何巧妙運用 JaCoCo 和 SonarQube 進行整合測試，並分享我多年來的實務經驗和獨到見解。

選擇與設定程式碼涵蓋範圍工具

SonarQube 內建 JaCoCo 和 Cobertura 兩種常用的 Java 程式碼涵蓋範圍工具，也支援透過外掛整合 EMMA 和 Clover。其他語言的涵蓋範圍工具則由對應的外掛提供。我建議在所有專案中維持預設的涵蓋範圍工具，避免因不同工具計算方式的差異造成混淆，也方便比較不同專案的健康狀況。

若需更改預設工具，可在全域設定頁面的 Java 類別中設定 sonar.java.coverage-Plugin 屬性，可接受的值包含 jacoco（預設）、cobertura、clover 或 emma。設定完成後，儲存 Java 設定並重新分析每個專案即可生效。

  graph LR
A[設定涵蓋範圍工具] --> B{Java 專案?}
B -- 是 --> C[設定 sonar.java.coverage-Plugin]
B -- 否 --> D[參考線上檔案]
C --> E[重新分析專案]

此流程圖展示了設定程式碼涵蓋範圍工具的流程。如果是 Java 專案，則需設定 sonar.java.coverage-Plugin 屬性，然後重新分析專案。若非 Java 專案，則需參考 SonarQube 的線上檔案。

整合測試的重要性與 SonarQube 的整合

整合測試如同十年前的單元測試一樣重要，尤其對於複雜系統，單元測試並不足夠，沒有充分的整合測試就無法確保軟體經過完善測試。整合測試著重於在近似生產環境中測試程式碼，包含所有外部資源。

SonarQube 能分別追蹤整合測試和單元測試的指標，讓你清楚瞭解兩者的狀況。我建議您將整合測試指標新增到儀錶板，以便隨時監控整合測試的品質。在 SonarQube 儀錶板設定的「測試」群組中，您可以找到並新增整合測試指標小工具。

利用 JaCoCo 建立整合測試報告

JaCoCo 是一款功能強大的工具，可以生成整合測試報告，不論您使用哪種工具執行測試。透過設定 sonar.jacoco.itReportpath 屬性，您可以指示 SonarQube 重用 JaCoCo 產生的報告，簡化整合流程。

整合測試覆寫率小工具與單元測試覆寫率小工具類別似，但它不提供關於測試本身的資訊，僅顯示測試覆寫程式碼的程度。「整體覆寫率」部分則描述了單元測試和整合測試的組合覆寫率，這項資訊非常有用，尤其當單元測試不適用時，我們仍可以將兩個指標彙總到一個結果中。

整合測試覆寫率的指標與單元測試覆寫率指標相同，包含：列覆寫率、分支覆寫率和測試覆寫率。在檔案層級，整合測試資料與單元測試覆寫率資訊整合在一起。

  graph LR
    B[B]
A[JaCoCo 產生整合測試報告] --> B{設定 sonar.jacoco.itReportpath}
B --> C[SonarQube 顯示整合測試覆寫率]
C --> D[分析程式碼覆寫率]
D --> E[提升程式碼品質]

此流程圖展示了使用 JaCoCo 和 SonarQube 進行整合測試的流程。JaCoCo 產生整合測試報告，設定 sonar.jacoco.itReportpath 後，SonarQube 顯示整合測試覆寫率，開發者可根據這些資料分析程式碼覆寫率，進而提升程式碼品質。

處理程式碼重複

即使是最有經驗的團隊，程式碼重複也難以完全避免。SonarQube 提供了有效的方法來追蹤和移除重複程式碼。透過儀錶板上的註解和重複小工具，以及「重複程式碼」的詳細分析和檔案詳細資訊檢視中的「重複程式碼」頁籤，可以輕鬆地在單個專案和跨多個專案中發現重複的程式碼塊。

減少程式碼重複可以降低維護成本、提高程式碼可讀性和減少錯誤發生的機率。我認為，定期使用 SonarQube 分析程式碼重複，並結合程式碼重構技巧，是維持程式碼品質的有效方法。

  classDiagram
    class SonarQube {
        -projectKey: String
        -projectName: String
        +analyze(project: Project): Report
    }

    class JaCoCo {
        -reportPath: String
        +generateReport(tests: Tests): Report
    }


    SonarQube -- JaCoCo: uses

此類別圖展示了 SonarQube 和 JaCoCo 之間的關係。SonarQube 使用 JaCoCo 產生的報告來分析程式碼覆寫率。

本文探討瞭如何結合 JaCoCo 和 SonarQube 進行整合測試，以及程式碼重複的處理方式。希望這些資訊能幫助您更好地理解整合測試和程式碼品質的重要性，並在實踐中應用這些工具和技術。

程式碼重複，如同程式碼函式庫中的雜草，滋生蔓延後會讓你的程式碼難以維護，猶如置身叢林，難以找到出口。試想一下，你正準備發布新版本，卻發現一個藏匿已久的 bug 導致折扣計算錯誤，而這個 bug 正是程式碼重複惹的禍！你可能需要耗費整個週末加班除錯，只因當初圖一時方便複製貼上了一段程式碼。

我曾親身經歷過這樣的場景，那種挫敗感至今記憶猶新。因此，我深刻體會到及早發現並清除程式碼重複的重要性。SonarQube 正是一款能幫助我們揪出這些程式碼「複製忍者」的利器。

程式碼重複：罪魁禍首是誰？

為什麼程式碼會重複？很多開發者會說：「我從不複製貼上程式碼！」，但實際上，幾乎每個人都或多或少地做過。這其中的原因複雜多樣，我總結了以下幾點：

時間壓力： 在 deadline 逼近時，複製貼上看似最快捷的解決方案，但卻埋下了日後維護的隱患。
迴歸風險： 缺乏完善的測試覆寫率，讓開發者不敢輕易修改程式碼，只好複製貼上，以求穩定。
懶惰： 直接複製貼上現成程式碼，省時省力，但卻是飲鴆止渴。
重構不足： 許多功能開發都是從複製現有程式碼開始，但後續的重構工作卻常常被忽略。
溝通不良： 團隊成員之間缺乏溝通，容易導致重複造輪子，尤其在大型團隊中更為常見。
誤解需求： 新手開發者容易直接複製看似符合需求的程式碼，卻未真正理解業務邏輯，導致程式碼混亂。
專案合併： 合併專案時，不同專案中可能存在功能類別似的程式碼，導致重複。

SonarQube：程式碼重複的剋星

SonarQube 能夠在不同層級檢測程式碼重複：檔案內、專案內，甚至跨專案。它提供了一套直觀的介面和指標，幫助我們快速定位和分析重複程式碼。

SonarQube 儀錶板：程式碼重複概覽

SonarQube 的專案儀錶板提供了一個程式碼重複小工具，展示重複行數、區塊數和檔案數，讓我們對專案的程式碼重複情況一目瞭然。

  graph LR
    C[C]
    D[D]
    subgraph "專案儀錶板"
        A[程式碼重複小工具] --> B{重複行數}
        A --> C{重複區塊數}
        A --> D{重複檔案數}
    end

此圖表展示了 SonarQube 儀錶板中程式碼重複小工具提供的資訊。

深入分析：逐層挖掘程式碼重複

點選小工具中的指標，可以進入更詳細的 Drilldown 檢視，檢視包含重複程式碼的套件和檔案列表，以及每個套件和檔案的重複指標。

  sequenceDiagram
    participant 使用者
    participant 儀錶板
    participant Drilldown檢視
    participant 檔案資訊

    使用者->>儀錶板: 點選指標
    儀錶板->>Drilldown檢視: 顯示套件/檔案列表
    使用者->>Drilldown檢視: 選擇檔案
    Drilldown檢視->>檔案資訊: 顯示檔案重複資訊

此序列圖展示了從儀錶板到檔案層級重複程式碼分析的流程。

在檔案資訊頁面中，「程式碼重複」頁籤會顯示重複程式碼的確切位置和內容，以及與哪些程式碼段重複。

  stateDiagram
    [*] --> 檔案資訊檢視
    檔案資訊檢視 --> 程式碼重複頁籤
    程式碼重複頁籤 --> 重複程式碼位置
    程式碼重複頁籤 --> 重複程式碼內容
    重複程式碼位置 --> [*]
    重複程式碼內容 --> [*]

此狀態圖描述了在檔案資訊檢視中檢視程式碼重複資訊的流程。

跨專案檢測：斬草除根

SonarQube 還支援跨專案重複程式碼檢測，這對於大型組織或有多個相關專案的情況尤為重要。啟用此功能後，SonarQube 會分析所有專案的程式碼，找出潛藏的跨專案重複程式碼。

重構之道：消除程式碼重複

發現程式碼重複後，我們需要採取有效的重構策略來消除它們，例如：

提取方法： 將重複程式碼段提取成獨立的方法，提高程式碼複用性。
繼承與多型： 利用物件導向的特性，減少類別間的程式碼重複。
設計模式： 運用策略模式、範本方法模式等設計模式，最佳化程式碼結構，減少重複。
程式碼重構： 簡化程式碼邏輯，消除冗餘程式碼，提高程式碼可讀性和可維護性。

持續使用 SonarQube 進行程式碼分析，並結合以上重構策略，才能讓你的程式碼函式庫保持健康，避免程式碼重複的「雜草」叢生。

SonarQube 指標：程式碼重複的量化指標

SonarQube 提供了以下指標來衡量程式碼重複的程度：

重複行數: 實際重複的程式碼行數。
重複區塊數: 重複程式碼塊的數量。
重複檔案數: 包含重複程式碼的檔案數量。
重複行密度: 重複行數佔總程式碼行數的百分比，更能反映程式碼重複的嚴重程度。

透過這些指標，我們可以更精確地評估程式碼重複問題，並制定更有針對性的重構計劃。

我始終認為，程式碼品質是軟體開發的根本。透過 SonarQube 等工具，並結合有效的重構策略，我們可以有效地控制程式碼重複，提升程式碼品質，最終交付更穩定、更易於維護的軟體產品。

消滅程式碼重複的藝術：重構與工具的完美結合

身為一個程式設計師，我經常思考如何提升程式碼品質。程式碼重複，猶如程式碼中的雜草，不僅影響程式碼的美觀，更會降低程式碼的可讀性、可維護性和可擴充性。這篇文章將探討如何利用程式碼重構和工具來有效識別和消除程式碼重複，並分享我在實務中的一些經驗和技巧。

程式碼重複的危害：潛藏的效能殺手

重複的程式碼如同軟體中的毒瘤，它會降低程式碼的可讀性、可維護性和可擴充性。當需要修改某段邏輯時，您必須在多個地方進行相同的修改，這不僅耗時費力，也容易造成遺漏或錯誤，猶如在除草時，必須一株一株拔除，費時費力。此外，重複的程式碼還會增加程式碼的體積，影響程式的執行效率，如同過多的雜草會搶奪作物的養分。

程式碼壞味道：如何嗅出重複程式碼

以下是一些程式碼中可能出現重複的徵兆，如同偵探尋找線索一般：

複製貼上： 這是最明顯的程式碼重複形式，當您發現自己正在複製貼上程式碼時，就要提高警覺，如同發現了罪犯的指紋。
高度相似的程式碼塊： 即使程式碼不完全相同，但如果不同程式碼塊的邏輯非常相似，也可能存在重複的程式碼，如同發現了罪犯的 DNA。
功能重疊： 如果不同的程式碼塊實作了相似的功能，也可能存在程式碼重複，如同發現了罪犯的作案手法。

  graph LR
A[複製貼上] --> B(程式碼重複)
C[高度相似的程式碼塊] --> B
D[功能重疊] --> B

以上圖表展示了複製貼上、高度相似的程式碼塊、功能重疊與程式碼重複之間的關係，這些都是程式碼重複的明顯特徵。

重構：程式碼的煉金術

重構是一種改善程式碼結構而不改變其外部行為的技術，如同煉金術一般，將粗糙的程式碼轉化為精煉的程式碼。它可以幫助我們消除程式碼重複，提高程式碼品質。以下是一些常用的重構技巧：

提取方法 (Extract Method)： 將重複的程式碼塊提取成一個獨立的方法，然後在需要的地方呼叫這個方法，如同將常用的工具整理到工具箱中，方便取用。
提取類別 (Extract Class)： 將重複的程式碼塊和相關的資料提取成一個獨立的類別，如同將相關的零件組裝成一個模組，提高程式碼的組織性。
繼承與多型： 利用繼承和多型來消除不同類別之間的程式碼重複，如同利用模具生產零件，減少重複的工作。

以下是一個程式碼重構的例子，展示如何將重複的程式碼提取到抽象類別中：

// 重構前
public class Order {
    // ... 省略其他程式碼 ...

    public BigDecimal getTotal() {
        BigDecimal total = calculateTotal();
        BigDecimal discount = total.multiply(BigDecimal.valueOf(0.10));
        total = total.subtract(discount);
        BigDecimal tax = total.multiply(BigDecimal.valueOf(0.20));
        total = total.add(tax);
        return total;
    }

    private BigDecimal calculateTotal() { /* 計算訂單總額的邏輯 */ }
}

public class InternationalOrder {
    // ... 省略其他程式碼 ...

    public BigDecimal getTotal() {
        BigDecimal total = calculateTotal();
        BigDecimal discount = total.multiply(BigDecimal.valueOf(0.10));
        total = total.subtract(discount);
        BigDecimal tax = total.multiply(customer.getCountry().getTax());
        total = total.add(tax);
        return total;
    }

    private BigDecimal calculateTotal() { /* 計算訂單總額的邏輯，與 Order 類別幾乎相同 */ }
}

// 重構後
public abstract class AbstractOrder {
    // ... 省略其他程式碼 ...

    public BigDecimal getTotal() {
        BigDecimal total = calculateTotal();
        BigDecimal discount = total.multiply(getDiscount());
        total = total.subtract(discount);
        BigDecimal tax = total.multiply(getTax());
        total = total.add(tax);
        return total;
    }

    protected abstract BigDecimal calculateTotal();

    protected BigDecimal getDiscount() { return BigDecimal.valueOf(0.10); }

    protected abstract BigDecimal getTax();
}

public class Order extends AbstractOrder {
    // ... 省略其他程式碼 ...

    @Override
    protected BigDecimal calculateTotal() { /* 計算訂單總額的邏輯 */ }

    @Override
    protected BigDecimal getTax() { return BigDecimal.valueOf(0.20); }
}

public class InternationalOrder extends AbstractOrder {
    // ... 省略其他程式碼 ...

    @Override
    protected BigDecimal calculateTotal() { /* 計算訂單總額的邏輯 */ }

    @Override
    protected BigDecimal getTax() { return customer.getCountry().getTax(); }
}

重構後的程式碼將計算訂單總額、折扣和稅額的共同邏輯提取到了 AbstractOrder 抽象類別中，並將 calculateTotal 和 getTax 方法定義為抽象方法。Order 和 InternationalOrder 類別繼承了 AbstractOrder 類別，並分別實作了這些抽象方法，從而消除了程式碼重複，提高了程式碼的可維護性。

工具輔助：SonarQube 的火眼金睛

SonarQube 是一款程式碼品質管理平台，可以幫助我們自動檢測程式碼中的重複程式碼，如同火眼金睛一般，找出程式碼中的瑕疵。它可以分析不同檔案、不同專案甚至跨專案的程式碼重複，並提供詳細的報告。

  sequenceDiagram
    participant 開發者
    participant SonarQube
    開發者->>SonarQube: 提交程式碼
    SonarQube->>SonarQube: 程式碼分析
    SonarQube->>開發者: 重複程式碼報告

以上 sequenceDiagram 展示了開發者使用 SonarQube 檢測程式碼重複的流程。開發者提交程式碼後，SonarQube 會進行程式碼分析，並將重複程式碼報告傳回給開發者。

除了 SonarQube，還有其他一些工具可以幫助我們檢測程式碼重複，例如 PMD、Checkstyle 等。選擇適合自己團隊的工具，並將其整合到持續整合/持續交付流程中，可以有效地防止程式碼重複的產生。

透過程式碼重構和工具輔助，我們可以有效地消除程式碼重複，提高程式碼品質。持續關注程式碼的壞味道，並積極採取措施進行改進，才能開發出乾淨、高效、易於維護的程式碼。如同園丁一般，持續地除草、施肥，才能讓程式碼花園茁壯成長。


在軟體開發的旅程中，程式碼檔案如同指引方向的燈塔，照亮前方的道路，讓開發者在程式碼的海洋中航行無阻。我發現，許多開發者往往低估了程式碼檔案的重要性，將其視為繁瑣的任務，草草了事。然而，一份精心撰寫的檔案，不僅能提升程式碼的可讀性，更能降低維護成本，讓團隊協作更加順暢。

## 程式碼檔案的價值：遠超您的想像

程式碼檔案的價值，並非僅僅停留在程式碼的表面，而是深入到程式碼的核心，揭示其設計理念、使用方法、特殊案例處理等關鍵資訊。這些資訊，往往是程式碼本身難以清晰表達的。

試想一下，當您接手一個沒有任何檔案的專案，或者面對一段充滿晦澀難懂程式碼時，您會是什麼感受？我相信，大多數開發者都會感到無比的痛苦和沮喪。

而一份完善的程式碼檔案，則可以幫助您快速理解程式碼的邏輯和功能，減少不必要的時間浪費，提升開發效率。

## 程式碼檔案的最佳實踐：我的經驗之談

多年來，我積累了一些程式碼檔案的最佳實踐，希望能幫助您更好地掌握程式碼檔案的藝術。

### 檔案內容：精準、完整、易懂

檔案的內容應該精準、完整與易懂。一份好的檔案，應該包含以下資訊：

* **功能描述：** 簡潔扼要地說明程式碼的功能，避免冗長和含糊不清的描述。
* **使用方法：** 詳細說明如何使用該程式碼，包括輸入輸出引數、傳回值、例外處理等。
* **設計理念：** 闡述程式碼的設計思路，例如使用的演算法、設計模式等，幫助讀者理解程式碼的底層邏輯。
* **特殊案例處理：**  說明程式碼如何處理邊界情況、錯誤情況等，讓讀者瞭解程式碼的健壯性。

```mermaid
graph LR
A[檔案內容] --> B(功能描述)
A --> C(使用方法)
A --> D(設計理念)
A --> E(特殊案例處理)

檔案生成方式：善用工具，事半功倍

選擇適合的工具，可以讓檔案生成事半功倍。以下是一些我推薦的工具：

Javadoc (Java): Java 的標準檔案生成工具，可以生成 HTML 格式的檔案。
NDoc (C#): C# 的檔案生成工具，功能類別似於 Javadoc。
Doxygen (跨平台): 支援多種程式語言的檔案生成工具，功能強大，可以生成各種格式的檔案。

  graph LR
A[檔案生成工具] --> B(Javadoc)
A --> C(NDoc)
A --> D(Doxygen)

程式碼範例：以身作則，清晰明瞭

以下是一個 Java 程式碼範例，展示瞭如何撰寫清晰的檔案：

/**
 * 計算兩個整數的和。
 *
 * @param a 第一個整數。
 * @param b 第二個整數。
 * @return 兩個整數的和。
 */
public int add(int a, int b) {
    return a + b;
}

這個 add 方法的功能是計算兩個整數的和。Javadoc 註解清晰地說明瞭方法的功能、輸入引數和傳回值。

複雜度管理：化繁為簡，深入淺出

對於複雜的程式碼，應該將其分解成更小的模組，並為每個模組撰寫清晰的檔案。這樣可以降低程式碼的複雜度，讓讀者更容易理解。

總結：程式碼檔案的藝術，精益求精

程式碼檔案是一門藝術，需要不斷地練習和精進。只有用心雕琢，才能寫出清晰、完整、易懂的檔案，提升程式碼的可讀性和可維護性，讓您的程式碼成為一件藝術品。

在軟體開發的領域中，程式碼的品質往往決定了專案的成敗。除了程式碼的正確性之外，可讀性、可維護性和可擴充性也同樣重要。而影響這些關鍵因素的兩個重要概念就是「內聚性」和「耦合性」。今天，我將以自身經驗出發，帶領大家深入瞭解這兩個概念，並分享一些實用的技巧，幫助你寫出更優雅、更易於維護的程式碼。

程式碼的內聚性：模組的專一性

內聚性指的是一個模組（例如類別或方法）內部各個元素之間的關聯程度。高內聚的模組意味著其內部元素都專注於完成單一、明確的任務，就像一支訓練有素的團隊，每個成員各司其職，共同完成目標。反之，低內聚的模組則像一盤散沙，各個元素之間缺乏關聯，職責不清，導致程式碼難以理解和維護。

舉例來說，一個負責使用者驗證的類別，如果同時包含了資料庫存取、日誌記錄等功能，就屬於低內聚。理想情況下，驗證、資料庫存取和日誌記錄應該由不同的模組負責，以提高程式碼的內聚性。

// 低內聚的例子
class UserAuthenticator {
    public boolean authenticate(String username, String password) {
        // ... 驗證邏輯 ...
        // ... 資料庫存取 ...
        // ... 日誌記錄 ...
    }
}

// 高內聚的例子
class UserAuthenticator {
    private final UserDatabase userDatabase;
    private final Logger logger;

    public UserAuthenticator(UserDatabase userDatabase, Logger logger) {
        this.userDatabase = userDatabase;
        this.logger = logger;
    }

    public boolean authenticate(String username, String password) {
        // ... 驗證邏輯 ...
    }
}

class UserDatabase {
    // ... 資料庫存取 ...
}

class Logger {
    // ... 日誌記錄 ...
}

高內聚的例子中，UserAuthenticator 類別專注於使用者驗證，而資料庫存取和日誌記錄則由 UserDatabase 和 Logger 類別負責，提高了程式碼的內聚性，也更易於測試和維護。

程式碼的耦合性：模組間的依賴性

耦合性指的是不同模組之間的依賴程度。低耦合意味著模組之間的依賴關係盡可能地少，就像一個運作良好的機器，每個零件可以獨立更換而不影響其他零件的運作。反之，高耦合則像一個糾纏不清的線團，改動一個模組可能會影響到其他模組，導致程式碼難以維護和擴充。

例如，如果一個模組直接依賴於另一個模組的具體實作，就屬於高耦合。理想情況下，模組之間應該透過介面或抽象類別進行互動，以降低耦合性。

// 高耦合的例子
class OrderProcessor {
    private final PaymentGateway paymentGateway = new PaypalPaymentGateway();

    public void processOrder(Order order) {
        paymentGateway.processPayment(order.getAmount());
    }
}

// 低耦合的例子
interface PaymentGateway {
    void processPayment(double amount);
}

class OrderProcessor {
    private final PaymentGateway paymentGateway;

    public OrderProcessor(PaymentGateway paymentGateway) {
        this.paymentGateway = paymentGateway;
    }

    public void processOrder(Order order) {
        paymentGateway.processPayment(order.getAmount());
    }
}

低耦合的例子中，OrderProcessor 透過 PaymentGateway 介面與支付閘道互動，而不依賴於具體的支付閘道實作，降低了耦合性，也更容易擴充功能，例如支援不同的支付方式。

視覺化內聚性與耦合性

  graph LR
    subgraph 高內聚
        A[模組 A] --> B(單一任務)
    end
    subgraph 低內聚
        C[模組 C] --> D(任務 1)
        C --> E(任務 2)
        C --> F(任務 3)
    end
    subgraph 低耦合
        G[模組 G] -- 介面 --> H[模組 H]
    end
    subgraph 高耦合
        I[模組 I] --> J[模組 J]
    end

圖表說明: 此圖表展示了高內聚、低內聚、低耦合和高耦合的示意圖，更直觀地理解這些概念。

我的觀點：平衡與取捨

在我多年的開發經驗中，我體會到追求高內聚、低耦合的設計並非一蹴而就，需要在實際開發中不斷權衡和取捨。有時，為了滿足特定的需求，可能需要犧牲部分內聚性或耦合性。關鍵在於理解這些概念的本質，並在設計和開發過程中做出明智的決策。

透過提升程式碼的內聚性和降低耦合性，我們可以開發出更具彈性、更易於維護和擴充的軟體系統。這不僅能提升開發效率，也能降低軟體的維護成本，最終提升軟體的整體品質。

在軟體開發的旅程中，程式碼的優雅性如同一位舞者，優雅的舞步能讓系統更易維護、更具彈性。我將帶您深入探索兩個關鍵指標：回應類別數 (RFC) 和耦合度，它們是衡量程式碼優雅程度的重要指標。

提升程式碼優雅度的關鍵指標：RFC

RFC，全名為 Response For Class，代表一個類別可能觸發的方法總數。這個數字越高，意味著這個類別的職責越多，理解和維護的難度也隨之增加。

想像一下，一個程式碼函式庫如同一個城市，每個類別都是城市中的一棟建築。RFC 高的類別就像一個大型購物中心，裡面應有盡有，但同時也人潮擁擠，管理起來非常複雜。在我的經驗中，RFC 超過 40 的類別往往需要特別關注，因為高 RFC 意味著對這個類別的任何修改都可能引發連鎖反應，影響到其他許多類別。

  graph LR
A[Class A (RFC: 50)] --> B[Class B]
A --> C[Class C]
A --> D[Class D]
A --> E[Class E]
A --> F[Class F]

圖表說明： 上圖展示了一個 RFC 過高的類別 A，它與其他五個類別都有互動。這種高耦合的狀態會增加程式碼的複雜度和維護成本。

降低 RFC 的實用技巧

當您發現程式碼的 RFC 過高時，可以嘗試以下方法：

職責拆分: 將大型類別拆分成更小的、職責更單一的類別。就像將大型購物中心拆分成不同的專賣店，每個店鋪只負責銷售特定型別的商品。
介面隔離: 使用介面定義類別之間的互動方式，降低類別之間的直接依賴。
設計模式: 運用適當的設計模式，例如策略模式、工廠模式等，簡化程式碼結構，降低耦合度。

程式碼範例：RFC 的計算

以下程式碼範例展示如何計算一個類別的 RFC：

class AmericanBreakfast {
    private Omelet omelet = new Omelet();
    private Coffee coffee = new Coffee();

    public void prepareOmelet() {
        omelet.prepare();
    }

    public void prepareDrinks() {
        coffee.brew();
        Juice orangeJuice = new Juice();
        orangeJuice.squeeze();
    }
}

AmericanBreakfast 類別的 RFC 為 4，它包含自身的兩個方法 (prepareOmelet 和 prepareDrinks)，以及它可以呼叫的 Omelet.prepare()、Coffee.brew() 和 Juice.squeeze() 方法。

耦合度：軟體設計的另一重要指標

耦合度描述了不同程式碼單元之間的依賴程度。低耦合的程式碼更易於修改和維護，因為修改一個單元不會對其他單元造成太大影響。

耦合度可以分為兩種：

傳入耦合 (Afferent Couplings): 指有多少其他類別依賴於這個類別。
傳出耦合 (Efferent Couplings): 指這個類別依賴於多少其他類別。

  graph LR
A[Class A] --> B[Class B]
C[Class C] --> B
D[Class D] --> B
B --> E[Class E]
B --> F[Class F]

subgraph " "
    Afferent Couplings of B: 3
    Efferent Couplings of B: 2
end

圖表說明： 上圖中，類別 B 的傳入耦合為 3，傳出耦合為 2。

降低耦合度的實用技巧

降低耦合度的方法與降低 RFC 的方法類別似，主要包括職責拆分、介面隔離和設計模式的運用。

RFC 和耦合度是衡量程式碼優雅性的重要指標。透過降低 RFC 和耦合度，可以提升程式碼的可讀性、可維護性和可擴充性，讓您的程式碼像一位優雅的舞者，在軟體開發的舞台上翩翩起舞。

善用 SonarQube 提升軟體設計

隨著專案的發展，程式碼的複雜度也隨之增加。本文將探討如何利用 SonarQube 這樣的工具來管理和降低軟體的複雜度，特別是在套件、模組和應用程式層級。

SonarQube 提供的依賴結構矩陣（DSM）能視覺化軟體元件之間的依賴關係，幫助我們識別和解決迴圈依賴等問題。此外，SonarQube 也能有效地檢查外部函式庫的依賴關係和版本衝突。

程式碼分層與信用卡計費功能的改進

假設我們需要在現有的信用卡處理功能基礎上，新增「每月硬幣」訂閱服務的定期信用卡計費功能。目前的系統只支援一次性付款，我們需要改進結帳流程以支援定期計費。

(後續內容將在下一篇文章中詳細說明如何利用 SonarQube 分析和重構程式碼，以實作新的定期計費功能，並保持程式碼的簡潔性和可維護性。)


在軟體開發的過程中，維持程式碼的清晰結構和可維護性至關重要。而迴圈依賴，如同程式碼中的藤蔓，纏繞交錯，讓程式碼難以理解、測試和修改。我將帶領各位深入瞭解迴圈依賴的危害，並分享如何使用 SonarQube 和依賴結構矩陣（DSM）來有效地識別和解決這個問題。

## 迴圈依賴的陷阱：牽一髮而動全身

迴圈依賴，簡單來說，就是多個模組彼此相互依賴，形成一個閉環。這種結構看似緊密，實則暗藏危機。它會導致程式碼耦合度過高，任何一個模組的修改都可能影響其他模組，如同多米諾骨牌效應，牽一髮而動全身，大幅增加開發和維護成本。此外，迴圈依賴也讓單元測試更加困難，因為模組之間的緊密耦合使得隔離測試變得異常複雜。

## SonarQube：程式碼品質的守護者

SonarQube 是一款強大的程式碼品質管理平台，如同程式碼的健康檢查儀，能幫助開發者找出程式碼中潛藏的各種問題，包含迴圈依賴。它提供的「Package Tangle Index」指標，能衡量專案中迴圈依賴的嚴重程度，數值越高，問題越嚴重。

## 程式碼範例：迴圈依賴的例項

以下 Java 程式碼範例展示了迴圈依賴的典型情況：

```java
// packageA/ClassA.java
package org.example.packageA;

import org.example.packageC.ClassC;

public class ClassA {
    private ClassC classC = new ClassC();

    public void doSomething() {
        System.out.println("doSomething");
    }
}

// packageC/ClassC.java
package org.example.packageC;

import org.example.packageD.ClassD;

public class ClassC {
    private ClassD classD = new ClassD();

    public String toString() {
        return "classC";
    }
}

// packageD/ClassD.java
package org.example.packageD;

import org.example.packageA.ClassA;

public class ClassD {
    private ClassA classA = new ClassA();

    public String toString() {
        return "classD";
    }
}

ClassA、ClassC 和 ClassD 三個類別互相依賴，形成了一個迴圈。ClassA 依賴 ClassC，ClassC 依賴 ClassD，而 ClassD 又依賴 ClassA，如同一個環，緊密相扣。

使用 SonarQube 分析這段程式碼，會發現 Package Tangle Index 指標偏高，顯示存在迴圈依賴。

依賴結構矩陣（DSM）：視覺化的依賴關係

SonarQube 提供的依賴結構矩陣（DSM）能以視覺化的方式呈現模組之間的依賴關係，如同程式碼的地圖，讓開發者清晰地看到哪些模組之間存在迴圈依賴，並找出需要修改的程式碼。

  graph LR
    A[packageA] --> C[packageC]
    C --> D[packageD]
    D --> A

這個圖表清楚地展示了 packageA、packageC 和 packageD 之間的迴圈依賴關係，形成了一個封閉的環狀結構。

解決迴圈依賴：重構程式碼，打破迴圈

解決迴圈依賴的核心就是重構程式碼，打破迴圈。常用的方法包括：

引入介面： 建立介面，讓迴圈依賴的類別依賴於介面，而不是直接依賴於彼此，如同在模組之間建立一個緩衝區。
重新設計類別： 重新分配類別的職責，將部分功能提取到新的類別中，減少類別之間的耦合度，如同將一個大型的、互相糾纏的程式碼塊拆分成更小、更獨立的單元。
依賴注入： 使用依賴注入框架，將依賴關係從程式碼中分離出來，由框架管理，如同將依賴關係的控制權交給一個專門的管理者。

針對上述程式碼範例，可以透過引入介面來解決迴圈依賴：

// InterfaceA.java
package org.example;

public interface InterfaceA {
    void doSomething();
}

// packageA/ClassA.java
package org.example.packageA;

import org.example.InterfaceA;
import org.example.packageC.ClassC;

public class ClassA implements InterfaceA{
    private ClassC classC = new ClassC();

    @Override
    public void doSomething() {
        System.out.println("doSomething");
    }
}

// packageD/ClassD.java
package org.example.packageD;

import org.example.InterfaceA;

public class ClassD {
    private InterfaceA classA;

    public void setClassA(InterfaceA classA) {
        this.classA = classA;
    }


    public String toString() {
        return "classD";
    }
}

透過引入 InterfaceA 介面，ClassD 不再直接依賴於 ClassA，而是依賴於 InterfaceA，成功打破了迴圈。

DSM 的解讀與應用：RICO 口訣

要深入理解 DSM，可以記住 RICO 口訣：Row-Incoming（列-傳入），Column-Outgoing（欄-傳出）。點選一個套件後，對應的行和列會以淡藍色突出顯示。行中的數字代表套件的傳入依賴，也就是此套件包含的其他套件；列中的數字則代表套件的傳出依賴，也就是包含此套件的其他套件。

  graph LR
    A[org.sonar.server.charts] --> B(org.sonar.server.charts.deprecated)
    C[org.sonar.server.platform] --> A

圖示：DSM 中選定套件的依賴關係

例如，上圖中，點選 org.sonar.server.charts 後，其描述以藍色突出顯示。它有一個傳入檔案依賴關係和六個傳出檔案依賴關係。

點選 DSM 中的儲存格，可以更精確地檢視兩個套件之間的依賴關係。點選的儲存格會變成紫色，相關套件會以不同顏色雙向突出顯示。

  graph LR
    A[org.sonar.server.charts] --> B(org.sonar.server.charts.deprecated)
    style B fill:#f9f,stroke:#333,stroke-width:2px
    style A fill:#ccf,stroke:#333,stroke-width:2px

圖示：點選 DSM 儲存格後的變化。所選套件之間的依賴關係以不同顏色雙向突出顯示。點選的儲存格也變成紫色。

透過 SonarQube 和 DSM，我們可以有效地識別和解決程式碼中的迴圈依賴問題，提升程式碼的可維護性和品質。持續使用這些工具，如同為程式碼定期體檢，能幫助我們及早發現和解決潛在問題，開發更健壯、更易維護的軟體系統。

在軟體開發的過程中，我們常常會遇到模組之間複雜的依賴關係，而這些錯綜複雜的關係中，隱藏著一個潛在的危機：迴圈依賴。我發現，迴圈依賴就像程式碼中的隱形殺手，它會降低程式碼的可維護性、增加除錯的難度，甚至導致系統當機。因此，及早發現並解決迴圈依賴至關重要。

本文將以我的經驗和理解，探討如何利用依賴結構矩陣（DSM）識別和消除迴圈依賴，並提供實用的程式碼重構技巧。同時，我也會分享一些在 Maven 專案中管理函式庫依賴的技巧，幫助您避免版本衝突等問題。

DSM：透視迴圈依賴的利器

DSM 以矩陣的形式清晰地呈現了專案中各個套件或檔案之間的依賴關係。當我第一次接觸 DSM 時，就被它簡潔直觀的呈現方式所吸引。它就像一張地圖，將專案的結構一目瞭然地展現在眼前。

在 DSM 中，紅色背景的數字就像警示燈，標示著存在迴圈依賴的位置。點選這些紅色區塊，就能看到需要移除的檔案依賴關係列表，精確定位問題所在，省去了我不少在程式碼中大海撈針的時間。

  graph LR
    A[A]
    B[B]
    C[C]
    A --> B
    B --> C
    C --> A
    style A fill:#f9f,stroke:#333,stroke-width:2px
    style B fill:#ccf,stroke:#333,stroke-width:2px
    style C fill:#aaf,stroke:#333,stroke-width:2px

上圖展示了一個典型的迴圈依賴場景：套件 A 依賴 B，B 依賴 C，而 C 又依賴 A，形成了一個閉環。DSM 能夠快速識別這種情況，並將其以醒目的紅色標示出來。

除了套件級別的 DSM，我們還可以深入到檔案級別，檢視特設定檔案的依賴關係。這有助於更精細地分析迴圈依賴問題，找出問題的根源。

解除迴圈依賴：重構的藝術

發現迴圈依賴後，如何有效地消除它們？我認為，關鍵在於釐清各個類別的職責，避免職責混亂。以下是一些我常用的重構策略：

職責上移： 將共同的職責提取到更高階別的類別中，避免重複程式碼，並簡化依賴關係。
新增類別： 如果現有類別職責過於龐雜，可以建立新的類別來分離職責，降低耦合度。
合併類別： 對於職責高度重疊的類別，可以考慮合併它們，減少程式碼冗餘。
重新組織套件： 調整套件結構，使依賴關係更加清晰合理，更容易理解和維護。

// 重構前：迴圈依賴
class A { public void callB() { new B().callC(); } }
class B { public void callC() { new C().callA(); } }
class C { public void callA() { new A().callB(); } }

// 重構後：引入介面和相依性注入
interface Operation { void execute(); }
class A implements Operation { private Operation next; public A(Operation next) { this.next = next; } @Override public void execute() { next.execute(); } }
class B implements Operation { private Operation next; public B(Operation next) { this.next = next; } @Override public void execute() { next.execute(); } }
class C implements Operation { @Override public void execute() { /* ... */ } }

重構前的程式碼存在 A -> B -> C -> A 的迴圈依賴。重構後，透過引入 Operation 介面和相依性注入，將依賴關係改為 A -> B -> C，解除了迴圈依賴。

Maven 依賴管理：掌控專案的命脈

在現代軟體開發中，我們大量使用第三方函式庫，而 Maven 簡化了函式倉管理的流程。然而，依賴的函式庫也可能帶來版本衝突等問題。對此，我建議使用 SonarQube 等工具來瀏覽和搜尋函式庫依賴，幫助我們快速定位和解決這些問題。

  graph TD
    LibA[LibA]
    LibB1[LibB1]
    LibB2[LibB2]
    LibC[LibC]
    Project[Project]
    Project --> LibA
    LibA --> LibB1
    LibA --> LibB2
    Project --> LibC
    LibC --> LibB2
    style LibB1 fill:#f99,stroke:#333,stroke-width:2px
    style LibB2 fill:#f99,stroke:#333,stroke-width:2px

上圖展示了專案的函式庫依賴關係。LibB 出現了兩個不同版本 (LibB1 和 LibB2)，可能導致衝突。SonarQube 可以幫助我們識別這種情況。

透過 DSM 分析、程式碼重構和 Maven 依賴管理，我們可以有效地解決迴圈依賴和版本衝突等問題，提升程式碼品質和專案穩定性。


現代軟體開發高度依賴第三方函式庫，有效管理這些依賴關係至關重要。本文將探討如何使用 Maven 解決依賴衝突，並利用 SonarQube 搜尋函式庫依賴關係和定義架構規則，進而提升程式碼品質和系統架構的穩健性。同時，我們也將探討技術債的償還策略以及程式碼品質的提升方法。

##  Maven：解決依賴衝突的利器

在多個函式庫相互依賴的複雜專案中，版本衝突是常見的困擾。Maven 提供了 dependencyManagement 機制來解決這個問題。透過在 pom.xml 的 dependencyManagement 區段中明確指定函式庫版本，可以確保所有子模組使用一致的版本，避免版本衝突。

```xml
<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>com.example</groupId>
            <artifactId>common-lib</artifactId>
            <version>1.2.3</version>
        </dependency>
    </dependencies>
</dependencyManagement>

上述程式碼片段展示瞭如何在 Maven 的 dependencyManagement 區段中指定 common-lib 函式庫的版本為 1.2.3。如此一來，所有依賴 common-lib 的子模組都將使用這個版本，有效避免了版本衝突。

藉由這個設定調整，您可以有效控制專案的依賴關係，確保專案使用預期的函式庫版本，提升應用程式的穩定性和可靠性。

SonarQube：快速定位函式庫使用情況

函式庫的廣泛使用為軟體開發帶來了便利，但也引入了潛在風險。例如，函式庫中發現安全漏洞時，如何快速找出哪些專案使用了受影響的版本？手動搜尋既費時又容易出錯。SonarQube 提供了便捷的方式來搜尋函式庫依賴關係：在專案的 “Libraries” 頁面點選 “Usages” 連結。

  graph LR
    A[專案 Libraries 頁面] --> B(Usages 連結) --> C[依賴關係檢視表格];

以上圖表展示了在 SonarQube 中搜尋函式庫依賴關係的途徑。透過 “Usages” 連結，可以直接導向依賴關係檢視表格，方便使用者快速定位函式庫的使用情況。

SonarQube 的依賴關係檢視表格顯示了在 SonarQube 中找到的所有函式庫版本，以及使用每個版本的所有專案/模組，讓您可以輕鬆掌握函式庫的使用情況。

定義架構規則：維護系統分層結構

現代系統大多根據多層架構，例如 MVC（模型-檢視-控制器）模式。SonarQube 允許您定義架構規則來規範層級之間的存取，確保程式碼符合預期的分層設計。這項功能適用於啟用了位元組碼分析的 Java 專案。

  graph LR
    A[Presentation Layer] --> B(Business Logic Layer);
    B --> C[Persistence Layer];

此圖表展現了 MVC 架構中各層級之間的互動關係。Presentation Layer 負責使用者介面，Business Logic Layer 處理業務邏輯，Persistence Layer 負責資料持久化。SonarQube 的架構規則可以幫助您及時發現並糾正不符合規範的程式碼，維護系統的良好架構。

精準掌控程式碼的結構：SonarQube 的架構約束規則

SonarQube 的"架構約束"規則允許開發者根據專案需求設定架構約束。您可以修改現有規則或複製多個規則副本，設定多個約束條件，後者更具彈性。建議賦予每個規則副本清晰易懂的名稱，例如 “PresentationLayerAccessRestriction” 或 “BusinessLogicPersistenceSeparation”。

設定 fromClasses 和 toClasses 屬性定義了規則的約束範圍。啟用後，新規則會將 fromClasses 類別存取 toClasses 類別的每個例項標記為問題。兩個輸入都接受類別名或套件名稱，並且可以使用萬用字元。

  graph LR
    subgraph 表現層
        A[JSF] --> B(Managed Beans)
    end
    subgraph 商業邏輯層
        C[EJBs]
    end
    subgraph 持續層
        D[JPA/Hibernate/MyBatis]
    end
    B --> C
    C --> D

上圖展示了典型的 Java EE 應用程式分層架構。透過架構約束規則，我們可以限制不同層級之間的直接存取，例如禁止表現層直接存取持續層，從而提高程式碼的可維護性和可測試性。

規則隔離是 SonarQube 的重要特性，每個規則都是獨立處理的，確保每個約束都被獨立評估，提供更精確的程式碼分析結果。

擬定策略，降低技術債

使用 SonarQube 分析專案後，您可能會發現程式碼中存在許多需要改進的地方，也就是技術債。處理任何規模問題的最佳方法是將其分解成更小的部分，從專案儀錶板中最突出的問題開始著手，例如程式碼中的錯誤或漏洞。逐步償還技術債，切勿操之過急。

SonarQube 的其他資料檢視與專案歷史

SonarQube 提供了多種資料檢視，例如樹狀圖、時間軸圖或程式碼地圖，可以幫助您更好地理解專案的程式碼品質。SonarQube 也記錄專案的歷史資料，並追蹤指標的趨勢變化，讓您可以評估改進措施的效果。

一切皆為元件：SonarQube 的元件化管理

在 SonarQube 中，所有程式碼都被視為元件。您可以針對不同的元件設定不同的品質標準，並追蹤每個元件的程式碼品質指標。這種元件化的管理方式可以幫助您更好地控制專案的程式碼品質，並更有效地管理技術債。


提升程式碼品質並非一蹴可幾，而是一場持續的馬拉松。我將分享一些使用 SonarQube 的實務經驗，幫助開發團隊有效管理和提升程式碼品質。從設定明確目標、選擇合適的程式碼重構策略，到利用 SonarQube 的趨勢分析和元件分析功能，本文將提供全方位的指導，並輔以實務案例和 圖表，讓您更清晰地理解和應用這些技巧。

## 設定目標與程式碼重構策略

設定清晰的程式碼品質目標至關重要。我建議從一兩個關鍵指標開始，例如降低程式碼重複率或提升測試覆寫率。逐步達成目標，建立團隊的信心，再逐步納入其他指標，最終掌控所有品質導向。

以下幾種程式碼重構策略，可依專案實際情況選擇：

* **穩紮穩打：** 每次修改程式碼時，順帶清理現有問題。優點是影響範圍小，缺點是改進速度較慢。
* **童子軍法則：** 讓程式碼比你發現它時更好。類別似穩紮穩打，但更強調積極主動的改進。
* **SonarQube 時間：** 每週或每個 sprint 安排專門時間修復 SonarQube 報告的問題，搭配「最差優先」策略，集中處理最嚴重的問題。
* **重構：** 徹底解決根本問題。當程式碼函式庫過於混亂，修補無效時，重構是必要的，但需要謹慎評估和執行。

```mermaid
graph LR
    B[B]
    SonarQube[SonarQube]
A[評估程式碼現況] --> B{決定重構策略}
B -- 穩紮穩打 --> C[小步改進]
B -- 童子軍法則 --> D[積極清理]
B -- SonarQube 時間 --> E[集中修復]
B -- 重構 --> F[徹底改造]

此圖表展示了不同重構策略的選擇路徑，根據程式碼現況決定最合適的方案。

追蹤程式碼品質的軌跡：SonarQube 的時間機器

SonarQube 的 Time Machine 儀錶板如同時間機器，讓我們追溯專案的歷史軌跡，觀察程式碼品質的變化趨勢。透過歷史表格和時間軸 widget，我們可以清晰地看到各個指標的演變，例如程式碼複雜度、規則遵循度和測試覆寫率。

設定事件標記，例如版本事件、設定檔事件和警示事件，可以保留重要的快照，避免被資料函式庫清理機制刪除。

深入 SonarQube 元件分析：掌控每個細節

SonarQube 將專案、模組、套件和檔案都視為元件，並提供細緻的指標分析。透過樹狀圖 widget 和元件檢視，我們可以逐層深入，從專案層級到檔案層級，全面掌控程式碼品質。

  graph TD
A[專案] --> B(模組)
B --> C(套件)
C --> D(檔案)

此圖表再次強調 SonarQube 元件分析的層級結構，方便讀者理解。

Python 程式碼範例：執行 SonarQube 掃描

以下程式碼示範如何在 Python 中使用 subprocess 模組執行 SonarQube 掃描：

import subprocess

def run_sonarqube_scan(project_key, project_version):
    try:
        subprocess.run(["sonar-scanner", 
                        "-Dsonar.projectKey=" + project_key,
                        "-Dsonar.projectVersion=" + project_version,
                        "-Dsonar.sources=."])
        print("SonarQube 掃描完成。")
    except FileNotFoundError:
        print("錯誤：找不到 sonar-scanner。請確認已安裝與位於 PATH 中。")
    except Exception as e:
        print(f"掃描過程中發生錯誤：{e}")

# 範例用法
run_sonarqube_scan("my-project-key", "1.0.0")

這段程式碼使用 subprocess.run() 執行 sonar-scanner 命令，並設定必要的 SonarQube 屬性。try...except 區塊用於錯誤處理。

持續改進，永不止步

程式碼品質的提升是一場永無止境的旅程。我建議持續監控程式碼品質指標，並定期檢視和調整策略。透過 SonarQube 的強大功能，搭配有效的策略和持續的努力，我們可以開發更高品質的軟體。

持續整合（CI）已是軟體開發的標準實務，但持續檢測卻常被忽略。本文將探討持續檢測的精髓，並闡述如何將 SonarQube 整合至開發流程，以提升程式碼品質並開發更健壯的軟體。

持續檢測的核心概念

持續檢測旨在及早發現程式碼潛在問題，例如程式碼重複、測試覆寫率不足和潛在錯誤。藉此，開發團隊能持續追蹤程式碼品質趨勢，並及時修正。

持續檢測應自動化執行，不佔用開發人員過多時間。理想情況下，它應與規律的建置流程（最好是持續整合，至少 nightly build）結合。

持續檢測能回答以下關鍵問題：

上週新增了多少重複程式碼？
昨天提交檔案的測試覆寫率如何？
上次迭代是否引入了關鍵問題？

藉由持續檢測和 SonarQube 的差異化檢視，這些問題的答案將一目瞭然。

持續整合的優勢

傳統開發模式中，建置通常手動執行，問題可能潛伏數週才被發現。持續整合工具讓建置流程自動化，問題能快速浮現。

持續整合的優勢：

縮短建立可執行檔的時間。
每次建置執行所有測試，問題立即通知團隊。
隨時提供最新版本供測試、演示或評估。

以下流程圖展示持續整合系統運作：

  graph LR
    C[C]
    A[開發者提交程式碼] --> B(版本控制系統);
    B --> C{CI 伺服器};
    C -- 觸發建置 --> D[建置結果];

此圖展示程式碼提交後，經版本控制和 CI 伺服器處理，最終產生建置結果的流程。

從手動轉向自動化建置是重要的思維轉變，持續整合的優勢不容忽視。

SonarQube 與持續檢測的整合

SonarQube 作為程式碼品質管理平台，與持續整合系統的整合至關重要。每次程式碼提交觸發 SonarQube 分析，結果整合至 CI 流程。

SonarQube 提供豐富功能：

差異化檢視： 比較不同版本程式碼品質變化。
版本比較： 分析不同版本程式碼差異。
熱點： 識別需關注的程式碼區域。
時光機： 追蹤程式碼品質歷史演變。

這些功能讓團隊更全面地瞭解程式碼品質現狀和趨勢，並及時改進。

持續檢測的最佳實踐

將 SonarQube 整合至 CI 流程，每次提交觸發分析。
定期檢視 SonarQube 結果並採取行動。
使用差異化檢視和版本比較追蹤趨勢。
利用熱點和時光機功能深入瞭解歷史演變。

持續檢測和 SonarQube 的整合能持續提升程式碼品質，開發更健壯可靠的軟體。

CI 伺服器與 SonarQube 整合進行持續檢查

設定 CI 後，即可整合 SonarQube。只需兩步驟：

決定專案分析頻率。
建立執行分析的 CI 作業。

下圖展示整合後的系統，一個基本的 CI 工作流程。SonarQube 由 CI 伺服器上的建置作業自動觸發。分析完成後，團隊無需手動觸發即可取得最新報告，程式碼簽入即自動完成。

  graph LR
    B[B]
    D[D]
    subgraph "程式碼簽入"
        A[簽入程式碼] --> B{觸發建置}
    end
    B --> C[建置觸發 SonarQube 分析]
    C --> D{SonarQube}
    D --> E[取得分析結果報告]
    subgraph "其他"
        F[取得最新變更] --> A
        E --> G[檢視報告]
    end

    style B fill:#ccf,stroke:#888,stroke-width:2px
    style C fill:#ccf,stroke:#888,stroke-width:2px
    style D fill:#ccf,stroke:#888,stroke-width:2px

此流程圖展示程式碼簽入後，如何觸發建置，進而自動觸發 SonarQube 分析，最終產生報告供團隊檢視的流程。藍色區塊代表自動執行的步驟。

使用 CI 工具自動建置程式碼函式庫，即可將持續檢查新增到系統中。接下來，我們將探討這樣做的原因。

持續整合的全域觀

CI 協助團隊持續追蹤並減少技術債。技術債類別似財務債務，從第一次程式碼提交開始累積，每次新增程式碼都會增加。

技術債有三種形式，與七個品質導向相關：

程式碼： 問題、重複、缺乏註解和檔案。
設計： 設計不良、複雜、低內聚高耦合、架構問題。
測試： 低測試覆寫率、難以維護的測試。

如同信用卡消費，有很多理由增加技術債。應定期償還技術債，否則將陷入惡性迴圈：

  graph TB
    B[B]
    A[新程式碼增加技術債] --> B{不處理技術債}
    B --> C[實作新功能時間增加]
    C --> D[系統難以維護]
    D --> E[生產力下降]
    E --> C

此流程圖說明不處理技術債的惡性迴圈，最終導致生產力下降。

擺脫僵局的方法是在專案生命週期中持續償還技術債。SonarQube 是實作此目標的寶貴工具。後續將探討如何使用 CI 伺服器自動化 SonarQube 分析，以及如何使用差異檢視追蹤變化。

使用 CI 觸發分析

許多 CI 伺服器可與 SonarQube 整合，例如 Jenkins 和 AnthillPro（免費開源），以及 Atlassian Bamboo（商業產品）。即使沒有直接整合，仍可透過在建置後觸發指令來使用 SonarQube。

以下將以 Jenkins 為例，說明整合步驟：

安裝 SonarQube Jenkins 外掛程式。
設定 SonarQube 安裝。
設定 SonarQube Runner。
設定觸發 SonarQube 分析的作業。(Java/C# 專案需確保作業執行建置。)

後續將詳細介紹每個步驟。

(以下未完成的部分將在後續切片繼續撰寫)


## SonarQube 持續程式碼檢測實戰

在現今快速迭代的軟體開發環境中，程式碼品質的持續監控至關重要。SonarQube 作為一款領先的程式碼品質管理平台，提供強大的持續檢測能力，協助開發團隊及時發現並解決程式碼問題，最終提升軟體品質。本文將探討 SonarQube 的持續檢測機制，並分享我在實務應用中的獨到見解。

### 持續檢測的核心概念與流程

持續檢測的核心目標是將程式碼品質監控融入到開發流程的每個環節，實作程式碼問題的早期發現和快速修復。SonarQube 提供了豐富的功能，例如程式碼規則檢查、程式碼覆寫率分析、程式碼複雜度分析等，幫助開發團隊全面掌控程式碼品質。

```mermaid
graph LR
    B[B]
    D[D]
A[程式碼遞交] --> B{SonarQube 分析};
B --> C[品質報告];
C --> D{問題修復};
D --> A;

上圖展示了 SonarQube 持續檢測的基本流程。開發者提交程式碼後，SonarQube 會自動執行程式碼分析，並產生品質報告。開發團隊根據報告中的問題進行修復，形成一個持續改進的迴圈。我認為，持續檢測的關鍵在於「持續」二字，唯有將程式碼分析融入每日的開發流程，才能真正發揮其效用。

Jenkins 與 SonarQube 的整合

將 SonarQube 整合到 Jenkins CI/CD 流程中，可以自動化程式碼分析，並將其與建置、測試等環節無縫銜接。

安裝 SonarQube 外掛程式： 在 Jenkins 中安裝 SonarQube Scanner 外掛程式。
設定 SonarQube 伺服器： 在 Jenkins 全域設定中組態 SonarQube 伺服器的 URL、認證資訊等。
設定 SonarQube Scanner： 設定 SonarQube Scanner 的安裝路徑。
在 Jenkins Job 中設定 SonarQube 分析： 在 Jenkins Job 的建置步驟中新增 Execute SonarQube Scanner 步驟，並設定相關引數，例如專案金鑰、程式碼路徑等。

  sequenceDiagram
    participant Jenkins
    participant SonarQube
    Jenkins->>SonarQube: 觸發程式碼分析
    SonarQube->>Jenkins: 回傳分析結果

上圖展示了 Jenkins 與 SonarQube 的互動流程。Jenkins 觸發程式碼分析後，SonarQube 執行分析並將結果回傳給 Jenkins，Jenkins 即可根據分析結果採取相應的動作，例如標記建置失敗、傳送通知等。我建議將 SonarQube 分析設定為建置後動作，以避免影響建置流程。

SonarQube 的差異化檢視與程式碼品質趨勢分析

SonarQube 的差異化檢視功能允許開發團隊比較不同時間點或不同版本之間的程式碼品質變化，精確掌握程式碼改進或惡化的趨勢。這對於追蹤程式碼品質的長期變化，以及評估程式碼重構的效果非常有幫助。

在專案儀錶板中，可以選擇不同的時間區段進行比較，例如與前一天、前一週或前一個月的結果比較。儀錶板會以彩色數字（綠色表示改善，紅色表示惡化）顯示各項指標的變化，例如新增問題數、已解決問題數、程式碼覆寫率變化等。

實務經驗分享： 我曾經在一個專案中使用 SonarQube 追蹤程式碼覆寫率的變化。起初，團隊的程式碼覆寫率只有 50% 左右。透過持續的程式碼重構和單元測試的補充，我們逐步將程式碼覆寫率提升到了 80% 以上。SonarQube 的差異化檢視功能幫助我們清楚地看到程式碼品質的提升趨勢，也激勵了團隊持續改程式式碼品質。

玄貓的 SonarQube 最佳實務建議

設定合理的分析頻率： 過於頻繁的分析會造成系統負載過重，而過低的頻率則無法及時發現問題。我建議每天分析一到兩次，並設定僅在程式碼有變更時觸發分析。
分析所有型別的程式碼： 不要只關注特定型別的程式碼，例如 Java 或 JavaScript。應該將所有型別的程式碼都納入分析範圍，以確保程式碼品質的全面提升。
善用程式碼品質閘門： 設定程式碼品質閘門，例如程式碼覆寫率必須達到一定標準才能透過建置。這可以有效地阻止低品質的程式碼進入生產環境。
定期檢視程式碼品質報告： 不要只是設定好 SonarQube 就置之不理。應該定期檢視程式碼品質報告，並根據報告中的問題進行修復。

透過以上實務技巧，搭配 SonarQube 強大的分析能力，相信您也能夠有效提升程式碼品質，開發更穩健、更可靠的軟體系統。

在軟體開發的浪潮中，程式碼品質如同船隻的穩固性，攸關專案的成敗。有效追蹤和管理程式碼問題，猶如航海中的燈塔，指引我們避開暗礁，駛向成功的彼岸。SonarQube 正是這樣一座燈塔，提供多種機制協助我們精準掌控程式碼品質，從問題的稽核追蹤、手動建立問題到追蹤問題狀態和生命週期，都能幫助我們更精確地掌握專案的健康狀況。

溯源追蹤：揭開問題的神秘面紗

如同偵探追溯犯罪現場的蛛絲馬跡，SonarQube 的稽核追蹤功能，讓我們能夠深入瞭解每個程式碼問題的完整歷程。點選問題的年齡標籤，如同開啟時光膠囊，呈現該問題從首次現身以來的所有變更，包括操作型別、時間和執行者。這份詳盡的記錄，猶如問題的「病歷表」，有助於我們追溯問題的根源，分析其發展趨勢，並制定更有效的解決方案。

手動標記：洞察潛藏的程式碼缺陷

儘管 SonarQube 的自動化規則已相當完善，如同精密的雷達系統，能偵測出大多數程式碼缺陷。但仍有一些潛藏的問題，如同隱形的敵機，難以被自動化規則捕捉。例如，某些程式碼風格問題或待辦事項，雖然不違反特定規則，卻可能影響程式碼的可讀性和可維護性。此時，我們可以化身為經驗豐富的飛行員，運用 SonarQube 的手動建立問題功能，將這些需要關注的程式碼片段標記出來，如同在地圖上標記潛在的危險區域，提醒團隊成員注意。

何時需要手動標記？

以下是一些需要手動建立問題的典型場景：

冗長的方法引數： 當方法引數過多，如同過長的隊伍，影響程式碼可讀性和可維護性時，可以建立手動問題，提醒開發者進行重構，精簡引數列表。
缺失的 API 檔案： 對於需要補充說明的 API，如同缺少路標的岔路口，容易讓使用者迷失方向，可以建立手動問題，提醒開發者完善 API 檔案。
待辦的重構任務： 對於計畫重構的程式碼片段，如同待修繕的橋樑，需要及時處理，可以建立手動問題，方便追蹤重構進度。
單元測試的不足： SonarQube 通常不會自動標記單元測試的問題，但我們可以手動建立問題，如同設立檢查哨，確保測試程式碼的品質。

問題狀態與生命週期：掌控問題的動態變化

SonarQube 提供了完善的問題狀態和生命週期管理機制，如同交通指揮系統，引導問題從發現到解決的整個流程。我們可以根據問題的嚴重程度、型別和負責人等條件，對問題進行分類別和排序，如同安排車輛的行駛路線，確保問題得到及時處理。同時，我們還可以追蹤問題的解決進度，如同監控車輛的行駛狀態，掌握問題的動態變化。

以下是一個 Mermaid 流程圖，展示了問題的生命週期：

  graph LR
    D[D]
A[發現問題] --> B{確認問題};
B -- 確認 --> C[指派問題];
C --> D{解決問題};
D --> E[驗證解決方案];
E -- 透過 --> F[關閉問題];
E -- 未透過 --> C;

SonarQube 提供的程式碼問題追蹤和管理機制，如同一個強大的工具箱，幫助我們精準掌控程式碼品質。透過善用這些工具，我們可以更有效地發現和解決程式碼問題，提升軟體開發效率，最終交付高品質的軟體產品。

在軟體開發的生命週期中，程式碼品質的維護如同守護神般至關重要。SonarQube 作為程式碼品質管理的利器，提供了強大的問題追蹤機制，協助開發團隊及早發現和解決潛在的程式碼缺陷。我將結合自身經驗，深入剖析 SonarQube 的問題追蹤功能，並分享如何透過高效的程式碼審查流程，將 SonarQube 的效用最大化。

SonarQube 問題追蹤：精準掌握程式碼健康狀況

SonarQube 的問題追蹤面板猶如專案的健康儀錶板，透過多個視覺化小工具，將程式碼問題的現況一目瞭然地呈現。

多維度問題追蹤：不同視角洞察問題

SonarQube 提供多種視角追蹤問題，例如「未解決問題依狀態」小工具，以圖表方式呈現不同狀態（開啟、重新開啟、已確認等）的未解決問題數量，點選數字即可檢視對應的問題列表。而「未解決問題依負責人」小工具則統計每位開發人員負責的未解決問題數量，方便追蹤個人工作進度。

  graph LR
    D[D]
    E[E]
    A[問題追蹤面板] --> B(依狀態);
    A --> C(依負責人);
    B --> D{問題數量};
    C --> E{負責人 & 問題數量};

圖表說明：SonarQube 問題追蹤面板提供不同視角追蹤問題。

此外，「我的未解決問題」小工具則顯示當前登入使用者負責的未解決問題，包含嚴重程度、標題和產生時間等資訊，方便個人管理待處理問題。

精準搜尋：快速定位問題根源

除了視覺化面板，SonarQube 也提供強大的搜尋功能，可以跨專案搜尋問題，並根據嚴重程度、狀態、負責人等條件篩選結果，如同搜尋引擎般快速定位問題根源。

行動方案：規劃程式碼改善旅程

面對眾多程式碼問題，擬定有效的改善策略至關重要。SonarQube 的行動方案功能允許將問題分組，並劃分階段，設定完成期限，讓程式碼改善工作更有條理，並方便追蹤進度。

程式碼審查的藝術：團隊協作的精髓

程式碼審查不僅是程式碼品質的把關者，更是團隊協作的精髓所在。我認為，一個成功的程式碼審查流程應該兼具莊重和活力，鼓勵開放討論，並建立透明的資訊分享機制。

程式碼審查的目的：不止於程式碼

程式碼審查的核心價值在於提供一個平台，讓團隊成員深入交流程式碼，分享知識、解決難題、統一程式碼風格，並在早期發現潛在錯誤。這不僅提升程式碼品質，更促進團隊成員的技術成長和團隊凝聚力。

參與者和時機：全員參與，定期舉行

程式碼審查應該鼓勵所有程式設計師參與，由資深開發者主導，定期舉行，例如每週一次或每個 sprint 中進行數次，以維持良好的程式碼品質和團隊協作氛圍。

地點和工具：營造專注的討論環境

程式碼審查的地點應選擇會議室或獨立的網路空間，避免在開發者的工位上進行，以減少幹擾。使用投影機將程式碼投影到螢幕上，方便所有成員共同檢視和討論。

議程和會議紀錄：透明化資訊分享

我建議使用 wiki 來管理議程和會議紀錄，方便團隊成員共同編輯和追蹤修改記錄。議程應包含固定專案，例如上次會議的待辦事項、SonarQube 中新增的 issues，以及討論佈景主題佇列。會議紀錄則記錄出席人員、討論內容和決策結果。

關注沉默的聲音：鼓勵全員參與

在程式碼審查過程中，應特別關注不常發言的成員，鼓勵他們表達意見，讓每個團隊成員都有機會貢獻和了解團隊的動態。

SonarQube 外掛程式：擴充套件功能，提升效率

SonarQube 提供豐富的外掛程式，例如 JIRA 外掛程式，可以將 JIRA 的 issue 數量整合到 SonarQube 中，作為專案指標追蹤，方便團隊掌握專案進度和程式碼品質狀況。

  graph LR
    B[B]
    A[SonarQube] --> B{JIRA 外掛程式};
    B --> C[Issue 數量整合];
    C --> D[專案指標追蹤];

圖表說明：JIRA 外掛程式將 issue 數量整合到 SonarQube 中。

透過 SonarQube 的問題追蹤機制和高效的程式碼審查流程，我們可以有效地管理程式碼品質，提升團隊協作效率，最終開發更健壯、更可靠的軟體系統。

在軟體開發過程中，程式碼品質的維護至關重要。SonarQube 作為一個程式碼品質管理平台，能有效協助開發者找出程式碼中的問題。而將 SonarQube 與 IDE 整合，更能大幅提升開發效率。本文將分享我使用 SonarQube 與 IDE 整合的實戰經驗和技巧，帶您瞭解如何更有效率地提升程式碼品質。

Issue 的分配與追蹤：團隊協作的關鍵

在團隊協作中，透過 SonarQube 分配 Issue 並追蹤處理進度非常重要。您可以直接在 SonarQube 網頁介面操作，或者透過 IDE 中的 Sonar Issues 檢視進行。我個人偏好使用 IDE 中的 Sonar Issue Edit 檢視，因為它能直接顯示 SonarQube 介面中的 Issue 摘要，並提供所有工作流程選項，包含分配 Issue。如果您在設定 SonarQube 伺服器時提供了登入憑證，甚至可以直接使用「Assign to Me」選項，非常方便。

如何在 IDE 中快速找到分配給您的 Issue？

如果您是透過 IDE 分配 Issue，Sonar Issues 標籤會自動更新以顯示新的分配。但如果您是透過 SonarQube 網頁介面操作，則需要手動同步。點選 Sonar Issues 標籤中的「Synchronize」按鈕即可同步 Issue 清單。

當 Issue 數量龐大時，如何快速找到分配給自己的 Issue 呢？您可以透過檢視選單中的排序選項，按照受託人排序 Issue。預設情況下，Issue 是按照嚴重性分組的；但如果您將分組設定為「None」，所有分配給您的 Issue 就會排列在一起。

更精確的篩選方式是使用檢視選單中的「Configure Contents」選項。您可以設定多個 Issue 篩選器，例如只顯示分配給您的 Issue、特定嚴重程度的 Issue，或是特定型別的 Issue，大幅提升效率。

  graph LR
A[設定 Issue 篩選器] --> B{選擇篩選條件}
B -- 分配給我 --> C[顯示我的 Issue]
B -- 嚴重程度 --> D[顯示特定嚴重程度 Issue]
B -- 類別型 --> E[顯示特定型別 Issue]

圖表說明：設定 Issue 篩選器可以根據不同的條件，例如「分配給我」、「嚴重程度」和「類別型」，篩選出符合條件的 Issue。

深入程式碼範例：未使用的變數

以下是一個簡單的 Java 程式碼範例，示範 SonarQube 如何偵測未使用的變數：

public class UnusedVariableExample {

    public static void main(String[] args) {
        int unusedVariable = 10; // 這個變數未被使用
        System.out.println("Hello, world!");
    }
}

這段程式碼宣告了一個整數變數 unusedVariable，並指定為 10，但後續程式碼中並沒有使用到這個變數。SonarQube 可以偵測到這種未使用的變數，並將其標記為問題。開發者可以根據 SonarQube 的提示移除或修正這些未使用的變數，提升程式碼的整潔度和可維護性。這個簡單的例子展示了 SonarQube 如何幫助開發者找出潛在的程式碼問題。在實際專案中，SonarQube 可以分析更複雜的程式碼，並提供更全面的程式碼品質報告。

流程圖範例：程式碼品質分析流程

  graph LR
    D[D]
    F[F]
    A[撰寫程式碼] --> B{程式碼提交};
    B -- 觸發建置 --> C[建置程式];
    C --> D{SonarQube 分析};
    D -- 產生報告 --> E[檢視報告];
    E --> F{修正問題};
    F --> A;

圖表說明：這個流程圖展示了從撰寫程式碼到修正問題的完整迴圈。開發者提交程式碼後，會觸發建置流程，然後 SonarQube 會自動分析程式碼並產生報告。開發者可以檢視報告並修正程式碼中的問題，形成一個持續改進的迴圈。

系統架構圖範例：SonarQube 與開發環境的整合

  graph LR
    subgraph 開發環境
        A[Eclipse IDE] --> B[SonarLint]
        B --> C[Git]
    end
    C --> D[持續整合伺服器]
    D --> E[SonarQube 伺服器]
    E --> F[程式碼品質報告]

圖表說明：這個架構圖展示了 SonarQube 在開發流程中的整合方式。開發者在 Eclipse IDE 中使用 SonarLint 進行即時程式碼分析，並將程式碼提交到 Git 儲存函式庫。持續整合伺服器會自動觸發 SonarQube 分析，並將結果呈現在程式碼品質報告中。

我的觀點：善用 IDE 整合，事半功倍提升程式碼品質

我認為，將 SonarQube 與 IDE 整合，能更有效地提升程式碼品質。透過 IDE 的即時程式碼分析和 Issue 管理功能，開發者可以在編寫程式碼的同時就發現並解決問題，避免問題累積到後期，造成更大的修改成本。這種「防微杜漸」的策略，能有效降低技術債，提升程式碼的可維護性和可讀性，最終提升整個團隊的開發效率。

## 深入剖析 SonarQube 專案許可權控管：賦能團隊自主性

管理程式碼品質，如同指揮交響樂團，每個成員各司其職，協調一致才能演奏出完美的樂章。SonarQube 提供了精細的許可權控管機制，如同樂團指揮般，讓團隊成員能自主管理各自的程式碼區塊，同時維持整體程式碼品質的和諧。本文將探討 SonarQube 的專案許可權控管，解析如何有效運用角色和群組，賦能團隊自主性。

### 專案許可權介面解析：一目瞭然的角色與群組組態

SonarQube 的專案許可權介面設計簡潔直觀，讓管理者能輕鬆掌握專案、使用者和群組之間的許可權分配。介面主要分為上下兩部分：

* **上半部：全域預設許可權設定**  此區塊定義了新建立專案的預設許可權。預設情況下，`sonar-administrators` 群組擁有所有新專案的管理員許可權，而匿名使用者和 `sonar-users` 群組則擁有使用者和程式碼檢視者許可權。管理者可以根據需求調整這些預設設定，例如，限制匿名使用者存取新專案。

* **下半部：個別專案許可權設定**  此區塊列出了所有現有專案，並顯示每個專案中各個角色的成員。透過「選擇」連結，管理者可以針對個別專案調整許可權設定，新增或移除特定群組或使用者的角色。


```mermaid
graph LR
    subgraph 全域預設許可權
        A[新專案] --> B(管理員：sonar-administrators)
        A --> C(使用者：任何人, sonar-users)
        A --> D(程式碼檢視者：任何人, sonar-users)
    end
    subgraph 個別專案許可權
        E[專案A] --> F(管理員)
        E --> G(使用者)
        E --> H(程式碼檢視者)
        I[專案B] --> J(管理員)
        I --> K(使用者)
        I --> L(程式碼檢視者)
        M["..."]
    end

圖表說明： 圖表清晰地呈現了全域預設許可權和個別專案許可權的結構。管理者可以透過此圖錶快速理解 SonarQube 的許可權組態邏輯。

SonarQube 三大角色：權責分明，各司其職

SonarQube 提供三種專案角色，權責分明，確保團隊成員在各自的職責範圍內有效運作：

管理員 (Administrator): 擁有最高的專案許可權，可以執行所有操作，包括修改專案設定、管理品質設定檔、執行分析、管理使用者許可權等。如同樂團指揮，負責整體專案的品質掌控。
使用者 (User): 可以瀏覽專案資訊、執行分析、提交問題、管理自己的品質設定檔等。如同樂團的演奏者，負責程式碼的編寫和維護。
程式碼檢視者 (Code Viewer): 只能瀏覽專案資訊和程式碼，無法執行分析或修改設定。如同樂團的觀眾，可以檢視程式碼，但不能參與演奏。

善用群組管理：化繁為簡，提升效率

當團隊成員眾多時，透過群組管理許可權能大幅簡化操作，提升效率。將使用者分配到不同的群組，再將許可權授予群組，即可一次性管理多個使用者的許可權。例如，將所有開發者分配到 developers 群組，然後將 developers 群組設定為特定專案的「使用者」角色，即可讓所有開發者擁有該專案的使用者許可權。

  sequenceDiagram
    participant 管理員
    participant SonarQube
    participant 開發者群組
    participant 開發者A
    participant 開發者B

    管理員->>SonarQube: 建立開發者群組 (developers)
    管理員->>SonarQube: 將開發者A、開發者B加入 developers 群組
    管理員->>SonarQube: 將 developers 群組設定為專案X的使用者角色
    開發者A->>SonarQube: 存取專案X (擁有使用者許可權)
    開發者B->>SonarQube: 存取專案X (擁有使用者許可權)

圖表說明： 此序列圖展示瞭如何透過群組管理許可權，簡化多個使用者許可權設定的流程。

最佳實踐：開發自主高效的程式碼品質管理團隊

以下是一些 SonarQube 許可權管理的最佳實踐，幫助您開發自主高效的程式碼品質管理團隊：

依據職責分配角色： 根據團隊成員的職責分配不同的角色，避免許可權過大或過小。
善用群組管理： 透過群組管理許可權，簡化操作，提升效率。
定期審查許可權設定： 定期審查許可權設定，確保許可權組態的合理性和安全性。
鼓勵團隊成員自主管理： 賦予團隊成員自主管理許可權，提升團隊的責任感和效率。

透過有效運用 SonarQube 的許可權控管機制，您可以開發一個權責分明、自主高效的程式碼品質管理團隊，讓每個成員都能在各自的領域發揮最大價值，共同演奏出完美的程式碼交響曲。

SonarQube 許可權設定：開發程式碼的銅牆鐵壁

身為台灣技術工作者，我深知程式碼安全的重要性。SonarQube 提供的許可權控管機制，如同城牆般守護著程式碼，讓我能精準掌控程式碼的存取許可權。

隱藏程式碼的秘密：`sonar.importSources` 屬性

sonar.importSources 屬性如同程式碼的隱身衣，控制著程式碼是否匯入 SonarQube。預設值 true 表示匯入，而 false 則讓程式碼隱藏，即使擁有檢視許可權也無法檢視。

大多數情況下，我們需要檢視程式碼以進行審查和分析。這時，「程式碼檢視者」角色就至關重要，透過設定，我們可以控制哪些人能檢視特定專案的程式碼，防止外洩。

許可權設定的藝術：根據專案調整策略

許可權設定如同武功招式，需根據不同情境調整。高機密專案需要銅牆鐵壁般的防護，而開放原始碼專案則可更開放，鼓勵社群參與。

高機密專案： 嚴格限制存取許可權，如同保護軍事機密。
開放原始碼專案： 採取開放策略，鼓勵社群貢獻。

許可權設定沒有絕對的標準答案，需根據專案的特性調整。

系統管理員：SonarQube 的最高統帥

系統管理員擁有 SonarQube 的最高許可權，能更改所有安全設定、安裝外掛程式、調整全域設定，並管理所有預設儀錶板和篩選器。「品質設定檔管理員」則專注於程式碼品質設定檔的管理。

預設情況下，這兩個角色都授予 sonar-administrators 群組，而該群組的唯一預設成員是管理員帳戶。建議建立新的管理員帳戶，並將自己和備用管理員加入 sonar-administrators 群組，方便許可權移交。

外掛程式：擴充 SonarQube 的功能

SonarQube 提供許多外掛程式，可與 LDAP、OpenID、Crowd 和 PAM 等本地驗證系統整合，簡化使用者管理，讓使用者以現有帳戶登入，無需額外記憶密碼。

  graph LR
    C[C]
    E[E]
    F[F]
A[使用者] --> B(程式碼檢視者)
B --> C{程式碼存取}
A --> D(系統管理員)
D --> E{全域設定}
D --> F{外掛程式管理}

此圖表展示了 SonarQube 中使用者、程式碼檢視者和系統管理員之間的關係。使用者可以被授予程式碼檢視者角色，獲得程式碼存取權。系統管理員則擁有更高許可權，管理全域設定和外掛程式。

  sequenceDiagram
    participant 使用者
    participant SonarQube
    使用者->>SonarQube: 登入
    SonarQube->>使用者: 驗證許可權
    alt 程式碼檢視者
        SonarQube->>使用者: 顯示程式碼
    else 系統管理員
        SonarQube->>使用者: 顯示管理介面
    end

此圖表展示了使用者登入 SonarQube 後的許可權驗證流程。系統根據使用者角色顯示不同介面。程式碼檢視者看到程式碼，而系統管理員看到管理介面。

設定專屬程式碼規則：開發高效 SonarQube 檢測

我根據不同專案需求調整程式碼檢測規則，善用 SonarQube 的彈性設定精準掌控程式碼品質。以下分享我的設定技巧：

建立個人化規則設定檔：複製與修改

SonarQube 預設提供多種語言的規則設定檔，是很好的起點，但我會複製並修改，避免影響其他專案。

從零開始或複製？

兩種方式：從零開始或複製現有設定檔。複製只需點選「複製」按鈕並命名。從零開始則點選對應語言的「建立」連結，填寫表單即可。

有些語言的設定檔建立表單允許上傳特定規則引擎的規則檔案。稍後我將說明如何從現有設定檔匯出規則，再匯入新設定檔。

建立設定檔後，點選名稱進入「程式碼規則」頁面編輯規則。從零開始則顯示空白規則列表和搜尋表單；複製則顯示所有已啟用規則。

所有使用者，即使匿名使用者，都能檢視設定檔中的規則列表。管理員則以可編輯的搜尋結果格式檢視，方便修改。

首次設定檔編輯與程式碼品質

「程式碼規則」頁面顯示設定檔中所有已啟用規則。每個規則旁有核取方塊和下拉式選單。勾選表示啟用，取消勾選則停用。

停用規則是最常見的修改操作。介面無遞交按鈕，修改立即生效，但搜尋結果不會即時更新。停用的規則會繼續顯示，直到重新整理或執行新搜尋。

  graph LR
A[選擇設定檔] --> B{複製或新增？}
B -- 複製 --> C[複製現有設定檔]
B -- 新增 --> D[建立空白設定檔]
C --> E[編輯規則]
D --> E
E --> F[儲存設定檔]

此流程圖展示了設定 SonarQube 規則設定檔的步驟。首先選擇設定檔，決定複製或新增。接著編輯規則並儲存。

我通常先停用不適用的規則，再調整嚴重程度和閾值。例如，若專案對程式碼行數限制較寬鬆，我會調整相關規則的閾值，避免過多誤報。

我也會根據程式碼審查流程調整規則嚴重程度。例如，需要人工審查的規則設定為「提示」；必須立即修復的設定為「錯誤」。

透過這些設定，我有效控制程式碼品質，並將 SonarQube 整合至開發流程，提升效率。

調整規則嚴重性是常見的需求。許多人認為預設嚴重性過於嚴格。規則嚴重性依設定檔設定，若要全域更改，需手動執行。

  graph LR
    B[B]
A[每個規則左邊的下拉選單] --> B{列出所有可能的嚴重性};
B --> C[目前設定檔中目前規則的嚴重性會醒目顯示];
C --> D[更改規則嚴重性，請從下拉清單中選擇];

每個規則旁的下拉式選單列出所有可能的嚴重性，目前設定檔中該規則的嚴重性會醒目顯示。更改嚴重性只需從下拉選單中選擇。變更會立即記錄。

變更後的規則或嚴重性不會立即反映在專案分析或指標中，需要重新分析受影響的專案。這些編輯可能造成品質資料波動，例如，嚴重性調整導致問題數量變化。實際上程式碼未變，只是看待它的方式改變了。

使用新設定檔版本的分析會在 SonarQube 中標記為事件。事件標記值得紀唸的事情。下次分析（套用新設定檔）會標記為設定檔變更事件，註明設定檔名稱和版本。帶有事件的分析不受自動資料函式庫清理影響，可長期記錄品質波動的時間和原因。

新增規則：探索與應用

…(待續，關於如何新增規則的內容)

深入剖析 SonarQube 規則設定檔：客製化與最佳實務

身為一位台灣的技術工作者，我經常使用 SonarQube 進行程式碼品質分析。一個設定良好的規則設定檔是確保程式碼品質的根本。以下我將分享在設定 SonarQube 規則設定檔時，一些我認為重要的客製化技巧和最佳實務。

精準掌控程式碼分析：規則引數微調

SonarQube 提供大量的內建規則，涵蓋各種程式碼品質導向。然而，預設的規則設定不一定適用於所有專案。我發現，微調規則引數是提升程式碼分析精準度的關鍵。

舉例來說，「認知複雜度」規則可以限制程式碼區塊的複雜度。預設的閾值可能過於嚴格或寬鬆。透過調整引數，可以更精確地控制允許的複雜度上限，避免誤報，並更有效地找出真正需要重構的程式碼。

  graph LR
A[分析程式碼] --> B{檢查規則引數};
B -- 引數過於嚴格 --> C[調整引數];
B -- 引數過於寬鬆 --> C;
C --> D[再次分析];

圖一：規則引數調整流程

提升團隊效率：規則描述擴充與註解

清晰的規則描述有助於團隊成員理解規則的目的和重要性。我建議在規則描述中加入實際的程式碼範例，並說明違反規則的後果。此外，善用規則註解功能，記錄修改規則的原因和考量，有助於團隊成員理解規則的演變過程，並促進知識分享。

複製規則：快速建立變體

複製規則功能可以快速建立現有規則的變體，並根據專案需求調整引數。例如，我們可以複製「避免使用魔術數字」規則，並針對不同的專案設定不同的例外值。

繼承設定檔：簡化管理與維護

對於大型專案或多個團隊，我建議使用繼承設定檔功能。建立一個基礎設定檔，包含通用的規則設定，然後讓子設定檔繼承基礎設定檔，並根據團隊的特定需求進行調整。這樣可以簡化設定檔的管理和維護，並確保規則設定的一致性。

  graph LR
A[基礎設定檔] --> B(子設定檔 1);
A --> C(子設定檔 2);
A --> D(子設定檔 3);

圖二：設定檔繼承架構

警示設定：即時監控程式碼品質

設定警示可以幫助我們即時監控程式碼品質，並在問題發生時立即採取行動。我建議根據專案的風險承受能力設定警示閾值。例如，對於核心模組，可以設定較低的閾值，以便及早發現問題。

變更追蹤與比較：提升設定檔管理效率

善用變更追蹤和比較功能，可以幫助我們瞭解設定檔的演變過程，並快速找出不同版本之間的差異。這對於設定檔的版本控制和問題排查非常有幫助。

透過以上技巧和實務，我們可以更有效地利用 SonarQube 提升程式碼品質，並開發更健壯的軟體系統。我個人的經驗是，持續調整和最佳化設定檔，才能確保程式碼分析的有效性和準確性。

在軟體開發生命週期中，程式碼品質的控管至關重要。SonarQube 作為一個程式碼品質管理平台，提供豐富的功能協助開發團隊追蹤並提升程式碼品質。其中，篩選器功能扮演著關鍵角色，能幫助我們快速鎖定特定專案、檔案，並依據各種指標進行分析。我將結合自身經驗，深入淺出地解析 SonarQube 篩選器的使用方法，並分享一些實務技巧，讓您精準掌控專案程式碼品質，提升管理效率。

建立您的第一個篩選器

進入 SonarQube 後，點選畫面左上角的「度量」連結，即可進入篩選器管理頁面。左側是管理常用篩選器和搜尋條件的區域，右側則顯示搜尋結果。新的篩選器必須新增到儀錶板才能生效，這部分我們稍後再談。

現在，讓我們建立一個篩選器，找出測試覆寫率低於 50% 的專案。在搜尋表單的「目標」欄位選擇「專案」，點選「更多條件」按鈕，在下拉式選單中選擇「指標」，接著點選「指標」按鈕，並在「測試」類別下選擇「覆寫率」。最後，設定條件為「<= 50%」。

  graph LR
    B[B]
A[目標：專案] --> B{指標：覆寫率};
B --> C[條件：<= 50%];

此流程圖清楚地展示了設定篩選條件的步驟，從選擇目標到設定指標和條件，一目瞭然。

點選「搜尋」按鈕，符合條件的專案就會顯示在結果區域。點選右上角的「另存為」連結，設定篩選器名稱和描述，並勾選「分享」選項，即可儲存並且團隊成員分享。儲存後，「另存為」按鈕會變成「複製」，方便您快速複製現有篩選器。新增的篩選器也會出現在左側的常用篩選器列表中。

客製化篩選器檢視

SonarQube 提供「清單」和「樹狀圖」兩種檢視模式。「清單」模式下，點選「變更欄位」按鈕，可以新增、移除或調整欄位順序，並點選欄位名稱進行排序。「樹狀圖」模式下，點選「變更樹狀圖」連結，可以設定「大小」和「顏色」指標，用於計算和顯示專案區塊，讓資料呈現更直觀。

進階篩選技巧：鎖定問題程式碼

我經常使用 SonarQube 篩選器來追蹤特定問題，例如找出特定時間段內修改過的特定型別檔案。以下是一個實際案例：

找出過去三個月內修改過的、檔名包含 print 字樣的 XML、JavaScript 和 WEB 型別檔案，並排除 Java 檔案：

資源型別和語言篩選： 選擇「檔案」作為資源型別，並透過「更多條件」選擇 XML、JavaScript 和 WEB 語言，同時排除 Java。
名稱篩選： 新增「名稱」條件，輸入 *print*，使用萬用字元 * 比對多個資源。
時間篩選： 新增「時間」條件，在「檢查」欄位輸入 90，表示只包含過去 90 天內修改過的檔案。
執行搜尋： 點選「搜尋」按鈕。

除了檔名，我們也可以使用檔案的 key 進行篩選，檔案 key 的組成方式為：專案/模組 key + 完整的套件名稱 + 檔案名稱。

差異篩選器：追蹤程式碼品質變化趨勢

追蹤程式碼品質的變化趨勢對於專案管理至關重要。差異篩選器可以幫助我們找出程式碼指標的變化，例如程式碼覆寫率的增減。

假設專案經理想要找出程式碼覆寫率自上次分析以來下降的資源，可以設定以下條件：

目標： 選擇所有資源型別（專案、子專案、目錄和檔案）。
指標： 選擇「覆寫率」。
值：選擇「自上次分析以來」。
條件： 選擇「<=」。
數值： 輸入「0」。

  graph LR
    B[B]
A[目標：所有資源] --> B{指標：覆寫率};
B --> C[條件：自上次分析以來 <= 0];

此流程圖展示瞭如何設定差異篩選器，找出程式碼覆寫率下降的資源。負值表示指標下降，透過設定「<= 0」，即可找到覆寫率下降或持平的資源。

結果中會顯示指標值、趨勢圖示以及變化量欄位，方便我們快速掌握程式碼品質的變化趨勢。

透過以上案例和技巧，相信您對 SonarQube 篩選器的使用方法有了更深入的瞭解。在實際應用中，您可以根據專案需求靈活運用這些技巧，更有效地管理和分析程式碼品質，提升開發效率。善用篩選器，讓您事半功倍！

SonarQube 對於程式碼品質的把關功不可沒，但隨著專案的累積和資料的增長，效能的維持就成了一門學問。我發現，妥善設定資料函式庫清理策略、通用設定以及在地化選項，能讓 SonarQube 長期保持最佳狀態。以下分享我的 SonarQube 設定秘笈，希望能幫助各位讀者開發更流暢的程式碼品質管理體驗。

資料函式庫清理：維持 SonarQube 輕盈的關鍵

如同定期清理電腦硬碟能提升系統效能，SonarQube 的資料函式庫清理也至關重要。大量的歷史資料會拖慢系統速度，影響分析效率。我建議定期清理過時的快照，只保留必要的資料。

在全域設定中，可以設定資料函式庫清理器的排程和保留規則。根據我的經驗，設定每月保留一個快照，並定期清理專案的歷史資料，就能有效控制資料函式庫大小，同時保留重要的歷史紀錄以供追溯。

通用設定：開發符合團隊習慣的 SonarQube

SonarQube 的通用設定相當豐富，涵蓋了程式碼分析規則、通知設定、安全性設定等多個方面。我認為，調整這些設定的關鍵在於理解團隊的開發流程和習慣。

舉例來說，程式碼分析規則的設定應該與團隊的程式碼規範保持一致。通知設定則需要考慮團隊成員的溝通方式和頻率。安全性設定更需要根據專案的安全性要求進行調整。

在地化：讓 SonarQube 更貼近台灣開發者

SonarQube 預設使用英文介面，對於台灣的開發者來說，使用中文介面能提升操作效率和理解度。我建議將 SonarQube 的介面語言設定為繁體中文，並使用台灣慣用的技術術語。

此外，在設定程式碼分析規則時，也需要考慮台灣的程式碼風格和規範。例如，變數命名、程式碼註解等方面，都應該符合台灣的習慣。

  graph LR
    I[I]
    subgraph 資料函式庫清理
        A[設定保留規則] --> B(定期清理)
    end
    subgraph 通用設定
        C[分析規則] --> D(通知設定)
        D --> E(安全性設定)
    end
    subgraph 在地化
        F[繁體中文介面] --> G(台灣術語)
        G --> H(程式碼規範)
    end
    B & E & H --> I{最佳化 SonarQube}

圖表說明： 此圖表展示了資料函式庫清理、通用設定和在地化如何共同作用，最佳化 SonarQube。

  classDiagram
    class SonarQube {
        +DatabaseCleaner databaseCleaner
        +GeneralSettings generalSettings
        +LocalizationSettings localizationSettings
    }
    class DatabaseCleaner {
        +RetentionRules retentionRules
    }
    class GeneralSettings {
        +AnalysisRules analysisRules
        +NotificationSettings notificationSettings
        +SecuritySettings securitySettings
    }
    class LocalizationSettings {
        +Language language
        +Terminology terminology
        +CodingConventions codingConventions
    }

    SonarQube "1" *-- "1" DatabaseCleaner
    SonarQube "1" *-- "1" GeneralSettings
    SonarQube "1" *-- "1" LocalizationSettings

圖表說明： 此圖表展示了 SonarQube 與其內部元件之間的關係，包含資料函式庫清理器、通用設定和在地化設定。

以上兩個圖表分別以流程圖和類別圖的形式，展示了 SonarQube 最佳化設定的關鍵要素及其相互關係。流程圖清晰地呈現了設定步驟，而類別圖則詳細說明瞭 SonarQube 的內部結構，有助於讀者更深入地理解 SonarQube 的設定機制。

透過以上設定技巧，我成功地將 SonarQube 開發成更符合團隊需求的程式碼品質管理平台。希望這些經驗分享能幫助各位讀者更有效地運用 SonarQube，提升程式碼品質，開發更優秀的軟體產品。

在軟體開發生命週期中，程式碼品質的持續監控和管理至關重要。SonarQube 提供了強大的工具和功能，協助開發團隊有效提升程式碼品質。本文將探討 SonarQube 的專案品質管理，從儀錶板的運用到持續整合的技巧，並分享我個人在實務應用中的一些心得和最佳實務。

專案儀錶板：掌握專案品質的全貌

SonarQube 的專案儀錶板如同專案的健康檢查報告，它以視覺化的方式呈現關鍵指標，例如程式碼行數、程式碼異味、漏洞數量、測試覆寫率等。開發團隊可以透過儀錶板快速掌握專案的整體品質狀況，並及時發現潛在問題。

  graph LR
A[專案儀錶板] --> B(程式碼行數)
A --> C(程式碼異味)
A --> D(漏洞數量)
A --> E(測試覆寫率)

這個圖表展現了專案儀錶板與其核心指標之間的關係。儀錶板作為中心節點，連線到各個指標，清晰地呈現了其功能和資訊架構。

更重要的是，專案儀錶板支援客製化設定。開發團隊可以根據自身需求調整小工具，顯示最相關的資訊。例如，我們團隊就曾因為專案特性，將「安全性熱點」的權重提高，以便更快速地發現潛在的資安風險。我認為，這種彈性化的設定是 SonarQube 的一大優勢。

多語言專案的品質管理

在現今的軟體開發環境中，多語言專案已成為常態。SonarQube 提供了強大的多語言支援，允許在單一平台上管理不同語言的程式碼品質。透過設定多個品質設定檔，針對不同語言套用不同的程式碼規範，確保每種語言的程式碼品質都能得到有效監控。

  graph LR
    B[B]
A[SonarQube] --> B{專案}
B --> C[Java]
B --> D[Python]
B --> E[JavaScript]

此圖表說明 SonarQube 如何管理多語言專案。一個專案可以包含多種程式語言，例如 Java、Python 和 JavaScript，SonarQube 可以同時分析這些語言的程式碼，並根據各自的品質設定檔進行評估。

品質設定檔：量身開發程式碼規範

品質設定檔是 SonarQube 的核心概念，它定義了一組程式碼規則和標準。開發團隊可以選擇預設的設定檔，或建立自訂設定檔，以符合專案的特定需求和程式碼風格。我個人建議，針對不同型別的專案（例如：網站應用程式、後端服務等）建立專屬的品質設定檔，可以更有效地管理程式碼品質。

專案歷史紀錄：追蹤程式碼演進

SonarQube 記錄每次程式碼分析的結果，形成專案的歷史紀錄。開發團隊可以追蹤程式碼品質的變化趨勢，瞭解程式碼改進的成效，並找出需要重點關注的區域。這個功能對於長期專案的維護和最佳化非常有幫助，可以讓我們清楚地看到程式碼品質的演進過程。

持續整合：將 SonarQube 納入開發流程

持續整合是現代軟體開發的最佳實務之一。將 SonarQube 整合到持續整合流程中，可以在每次程式碼提交時自動執行程式碼分析，及早發現和解決程式碼品質問題。我發現，這種做法可以有效地提升團隊的程式碼品質意識，並減少程式碼缺陷的產生。

SonarQube 資料函式庫清理策略：維持系統效能

隨著時間推移，SonarQube 的資料函式庫會累積大量的快照資料，影響系統效能。設定資料函式庫清理策略，可以有效控制資料函式庫大小，提升系統運作效率。我建議定期檢視和調整資料函式庫清理設定，確保 SonarQube 的穩定執行。

透過以上功能和技巧，SonarQube 提供了一個全面的程式碼品質管理平台，協助開發團隊有效提升程式碼品質，降低開發成本，並最終交付高品質的軟體產品。持續學習和探索 SonarQube 的新功能，並將其融入到日常開發流程中，將持續提升團隊的程式碼品質和開發效率。


在程式碼品質管理的旅程中，SonarQube 提供了強大的工具和指標，協助開發團隊持續追蹤和提升程式碼的健康狀況。本文將探討 SonarQube 的專案設定與指標管理，讓您更有效地運用這個平台。

## 自訂指標：掌握專案的獨特導向

SonarQube 內建的指標涵蓋了程式碼的許多導向，但有時您需要追蹤一些 SonarQube 無法自動計算的指標，例如團隊資訊、專案預算或業務價值。此時，SonarQube 的「手動指標」功能就派上用場了。

### 新增手動指標

新增手動指標需要全域管理員許可權。步驟如下：

1. 點選右上角的「設定」連結，選擇「設定」。
2. 點選「手動指標」。
3. 輸入指標的名稱、描述和網域，並選擇指標型別（整數、浮點數、百分比、等級、文字組、是/否）。
4. 點選「建立」按鈕。

```mermaid
graph LR
    C[C]
A[設定] --> B(設定)
B --> C{手動指標}
C -- 建立 --> D[團隊名稱/ID]

此流程圖清楚地展現了新增手動指標的步驟，讓讀者更容易理解操作流程。

設定手動指標的度量值

設定手動指標的度量值，讓您可以針對每個專案指定特定的值。

選擇要設定的專案，點選「設定」下拉式選單中的「手動度量」。
點選「新增度量」連結。
選擇手動指標，填寫值和描述。
儲存設定。

設定完成後，需要執行新的專案分析，才能將手動度量值與其他 SonarQube 指標整合。

  graph LR
    C[C]
A[設定] --> B(手動度量)
B --> C{新增度量}
C --> D[值]
C --> E[描述]

這個流程圖簡潔地說明瞭如何設定手動指標的度量值，並強調了儲存設定和執行新分析的重要性。

在儀錶板中顯示自訂度量

將自訂度量小工具新增到儀錶板，即可顯示自訂指標的值。自訂度量小工具會顯示上次專案分析期間整合的最新指標值，並可整合到時間軸小工具中，檢視歷史演變。

從分析中排除原始碼

有時您需要從 SonarQube 分析中排除特定的檔案，例如修復後的第三方程式函式庫檔案。SonarQube 提供了多種排除方式：

SonarQube 核心排除功能: 根據檔案路徑模式排除原始碼和測試檔案。
關閉違規外掛程式: 針對特定問題停用規則，而不修改品質設定檔。
截止外掛程式: 根據特定條件排除檔案。

您可以根據需求選擇適合的排除方式，甚至可以組合使用。

  gantt
    title 排除方式比較;
    dateFormat  YYYY-MM-DD;
    axisFormat  %m-%d;

    section SonarQube 核心排除功能;
    忽略原始碼檔案       :a1, 2024-01-01, 30d

    section 關閉違規外掛程式;
    繞過問題建立        :after a1, 20d

    section 截止外掛程式;
    依據特定條件排除    :after a1, 40d

    section 組合使用;
    根據需求組合        :after a1, 60d

甘特圖清楚地比較了不同排除方式的適用場景，方便讀者快速選擇合適的方案。

專案歷史紀錄與設定

SonarQube 的專案歷史紀錄功能可以追蹤每次程式碼分析的結果、專案版本和重要事件。您可以透過「歷史紀錄」頁面瀏覽這些資訊，並執行重新命名、移除和刪除快照等操作。

其他專案設定

SonarQube 還提供其他專案設定選項，例如：

修改許可權: 為每個專案指派使用者角色，管理專案安全性。
設定專案連結: 新增外部連結，方便存取相關資源，例如專案首頁、CI 系統和問題管理系統。

透過深入瞭解 SonarQube 的專案設定和指標管理功能，您可以更有效地掌控程式碼品質，並根據專案的獨特需求進行客製化設定。我建議您實際操作這些功能，體驗 SonarQube 的強大威力。

在 SonarQube 中，專案管理至關重要，有效地管理專案能確保資料的完整性和分析結果的準確性。本文將探討 SonarQube 的專案管理技巧，包含修改專案鍵值、刪除專案以及客製化外掛程式開發。

修改專案鍵值：避免資料錯亂的關鍵

SonarQube 使用鍵值來識別專案。修改鍵值看似簡單，但若操作不當，可能導致資料混亂。想像一下，您的專案已累積大量歷史資料，若直接修改鍵值，SonarQube 可能將其視為新專案，造成資料重複和混亂。

我建議的解決方案是在 SonarQube 使用者介面中修改專案鍵值，步驟如下：

在專案的「設定」下拉式選單中，選擇「更新鍵值」。
輸入新的專案鍵值，然後點選「重新命名」。

確保原始碼/分析屬性中的專案鍵值與 SonarQube 中的專案鍵值一致，才能避免問題。

刪除專案：單個刪除與批次刪除

SonarQube 提供兩種刪除專案的方式：

單個刪除： 在專案的「設定」下拉式選單中選擇「專案刪除」，確認後即可刪除。此操作不可逆，請務必確認或事先備份資料函式庫。

批次刪除： 在全域設定選單中選擇「批次刪除」，勾選要刪除的專案，或使用「全選」功能。需要注意的是，不同頁面之間的選擇不會被記住，若要刪除跨頁面的專案，請使用「全選」右側的連結。批次刪除操作同樣不可逆。

  graph LR
    B[B]
    C[C]
A[選擇刪除方式] --> B{單個刪除}
A --> C{批次刪除}
B --> D(設定選單)
C --> E(全域設定選單)

圖表說明： SonarQube 專案刪除流程，可選擇單個刪除或批次刪除，分別對應不同的設定選單。

開發您的 SonarQube 外掛程式：完整

開發 SonarQube 外掛程式能擴充套件其功能，例如整合外部工具、產生客製化報告、新增語言支援等。本章將以整合 SonarQube 和 Redmine 為例，逐步引導您開發外掛程式。

在開始之前，瞭解 SonarQube 的內部運作機制至關重要，特別是裝飾器和感測器之間的區別，以及它們在分析期間的執行時機。

  graph LR
    C[C]
A[啟動分析] --> B(載入外掛程式)
B --> C{裝飾器執行}
C -- 完成 --> D[感測器執行]
D -- 完成 --> E[產生報告]

圖表說明： SonarQube 分析流程，首先載入外掛程式，接著執行裝飾器，然後執行感測器，最後產生報告。

本將涵蓋外掛程式開發的各個導向，包括新增指標、類別載入、相依性注入、小工具建立等。開發外掛程式需要熟悉 Java、jRuby 和 Ruby on Rails，並使用 Maven 進行構建。

這個客製化外掛程式的開發，能讓您更深入地掌控 SonarQube，並根據專案需求開發更精確的程式碼品質管理平台。

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。