改善程式碼品質從 SonarQube 開始！

軟體開發經常會⾯臨到的幾個挑戰

• 如何能夠可靠？
• 如何能夠安全？
• 如何能夠好維護？

Code Review 的挑戰

• 對 Reviewer 而言，他可能會需要參照某些審查檢核表來做查核。
• 對 Programmer 而言，由於專案很趕，當然先寫一個版本，剩下以後再說啦。

但倘若能導入 SonarQube 來協助 Code Review 就有機會可以改善上述情況！

• 協助 Reviewer 可以較容易進行 Code Review，因為有畫面可以看。
• 協助 Programmer 可以隨時了解自己所撰寫程式碼的品質。
• 軟體品質資料，⼤家都看得到，可以互相督促。
• 機器不受情緒影響，比較客觀。

SonarQube 品質資料解讀

以下將逐一頁籤去解讀資料！

總覽（Overview）

品質分級

TDR = Technical Debt Ratio

資料來源：https://docs.sonarsource.com/sonarqube/latest/user-guide/code-metrics/metrics-definition/#maintainability

技術債（Technical Debt）

• Design / Code Debt
  • 不良的設計（高耦合、低內聚、缺乏彈性、不易擴充）
  • 不良的程式碼撰寫風格
• Testing Debt
  • 缺少自動化測試、測試計劃
• Document Debt
  • 缺少文件
• Defect Debt
  • 已知但未解的缺陷

技術債比（Technical Debt Ratio）

以上圖案例來計算，技術債為 100 天（SonarQube 定義 1 天為 8 小時），程式總行數為 27000 行。

計算方式

技術債比 ＝ 技術債 ／（開發一行程式碼的時間成本 ＊ 程式總行數）

技術債：100 ＊ 8 ＊ 60 ＝ 48000 分鐘

開發一行程式碼的時間成本：30 分鐘（SonarQube 預設值，可以被改變）

程式總行數：27000 行

技術債比：48000 ／（30 ＊ 27000）≒ 0.06

SonarQube v10.6 之前開發一行程式碼的時間成本會被固定為 0.06 天，換算後為 28.8 分鐘（0.06 ＊ 8 ＊ 60），算出來的結果跟上面不會差太多！

經過以上計算，可以得知該專案可維護性會被評為 B 等級（＃品質分級）。

上述計算都以分鐘為基準，當然你若以天為基準，算出來的結果也會一樣！

唯一要注意的是，若你以分鐘為基準時，對 SonarQube 而已 1 天只會有 480 分鐘哦...

技術債比越小越好，代表可維護性會越高！

品質門檻（Quality Gate）

若仔細看 Measures 會有兩個頁籤，其中 New Code 表示它關注的是新提交上來的程式碼。

換句話說，每當你提交新的程式碼，都會再重新檢測一次這道品質門檻！

可以成功通過品質門檻的條件如下（預設值，可以被改變），對新程式碼而言：

• 沒有新的問題（Issue）產生
• 所有新的安全熱點（Security Hotspots）都已被檢視過（Reviewed）
• 測試涵蓋率 >= 80%
• 重複程式碼率 <= 3%

品質門檻的用意就在於期望你每次新提交的程式碼都可以符合其規則，自然就能維持程式碼品質！

至於 Overall Code 它關注的是整個程式碼庫（Codebase），從中可以發現以前尚未修復的缺陷，而你就必須再找時間來修復它！而不是放著就沒事了…

問題（Issues）

嚴重性

SonarQube >= v10.2

• Blocker、Critical 已被合併為 High。
• Major 已變成 Medium。
• Minor、Info 已被合併為 Low。

SonarQube < v10.2

• Blocker：高機率會影響應用程式在生產環境中行為的錯誤（例如：記憶體洩漏）。
• Critical：低概率會影響應用程式在生產環境中行為的錯誤或者是一個安全性漏洞（例如：SQL 注入）。
• Major：可能高度影響開發者生產力的品質缺陷（例如：未測試的程式碼、重複的區塊或未使用的參數）。
• Minor：可能稍微影響開發者生產力的品質缺陷（例如：行數不應該太長、switch 語句應該至少有三個案例）。
• Info：既不是錯誤也不是品質缺陷，只是一個發現。

Blocker、Critical、Major 應優先處理，至於 Minor、Info 則可以評估後再決定！

至於問題為什麼會發生？可以至 Rule 選單尋找並了解！

反白較明顯者，表示該項目已被選取，可以用來縮小搜尋範圍，甚至可以找出是誰調整的！

資料來源：https://docs.sonarsource.com/sonarqube/10.3/user-guide/issues/#severity-mapping

安全熱點（Security Hotspots）

這邊會列出一些疑似的安全性風險，供開發人員可以做後續評估是否還有討論空間…

若覺得沒什麼問題，可以點選 Change status 改變狀態！

安全熱點會影響（＃品質門檻）是否能成功通過哦！

測量（Measures）

Overview 會將資料以圖表的方式來呈現，較為直觀！

細部資料可以展開左側選單了解！

程式碼（Code）

可以初步了解程式碼測試涵蓋情況！

• 綠色：已涵蓋
• 紅色帶白色螺旋紋：部分涵蓋
• 紅色：未涵蓋

活動（Activity）

可以用來查詢一段時間區間的資料變化，藉此了解專案的走向（是否更好或更壞）！

以該案例來看，我想了解版本事件且時間區間為 2024/01/01 ~ 2024/06/26 的資料狀況。

版本事件：由外部服務觸發 SonarQube 掃描，外部服務可能像是 Jenkins…等持續整合平台

以該案例圖表來看，Bug 和 Vulnerabilities 沒什麼變化是好事，但 Code Smells 仍有改善空間…（Code Smells 若一直不處理，嚴重的話，是有可能會變成 Bug 哦）

另外它有提供一個功能，讓你可以選擇你想看的指標！

若是看技術債比，就可以了解專案是不是往好維護的方向走！

若是看重複率，就可以了解專案程式碼有沒有再改善的空間！

總結

對 Reviewer 而言，越早 Code Review 越好

• 為了找出和矯正技術債，同時間也一定程度會減慢了團隊前進的速度，因為開發團隊可能導入更多的⼈⼯控制，例如「變更管理」和「增加管理流程」。
• 建議技術債的矯正應在開發早期就開始進⾏且盡量不要使⽤變更審閱委員會機制（Change Review Board，CRB），⽽是使⽤同行評審機制（Peer Review）和⾃動測試，可以加快 Review Change 的速度。
• 若能達到上述目標，將有機會往下⼀階段的⾃動化和⾼效 DevOps 前進。

由上圖可以得知，隨著時間往後推移，調整程式碼的成本只會越來越高！

對 Programmer 而言，第⼀⾏就應該是 Clean Code

• 培養良好的單元測試習慣，降低 Bug 數量，提升軟體可靠性。
• 提早進⾏系統弱點掃描，降低 Vulnerabilities 數量，提升軟體安全性。
• 培養開發階段良好的程式碼撰寫習慣，盡量遵守 Clean Code 原則，降低 Code Smell 數量，提升軟體維護性，最好在 POC 階段就開始。
• 降低 Code Smell 數量，也就是降低技術債比，意即在每單位的開發成本中，矯正程式碼的成本越低，所⽤天數越少，我們越有機會提早進入生產環境（Production），建議開發環境要安裝 SonarLint。

SonarLint：大部分 IDE 或 Editor 可以安裝的擴充功能，協助 Programmer 可以在 SonarQube 掃描之前就能提前得知問題並予以修正！

測試左移（Shift-left testing）的影響

以軟體開發的時間軸來看，把產品發佈的時間點當作里程碑。

在產品上線發佈前，盡早開始測試計劃與項目，力拼在左側完成測試。

像是測試驅動開發（TDD）或是行為驅動開發（BDD）都是測試左移的概念應用。

目的也是確保能做對的事並跟產品的業務目標緊密配合。

這也是為什麼敏捷開發與 DevOps 這麼推崇測試左移的概念。

藉由持續收集反饋與改進驗證，來確保產品是否符合預期。

參考

第十二卷 - 測試左移的美麗與測試右移的哀愁（上）