玩轉Sonar

轉載自: ​​https://taosha.club/topic/61c2c6e9d59b034e2c167a54​​

Sonar介紹

Sonar 是一個用于代碼品質管理的開放平台。通過插件機制，Sonar 可以內建不同的測試工具，代碼分析工具，以及持續內建工具。與持續內建工具（例如 ​

​Hudson/Jenkins 等​

​）不同，Sonar 并不是簡單地把不同的代碼檢查工具結果（例如 ​

​FindBugs，PMD​

​ 等）直接顯示在 Web 頁面上，而是通過不同的插件對這些結果進行再加工處理，通過量化的方式度量代碼品質的變化，進而可以友善地對不同規模和種類的工程進行代碼品質管理。

在對其他工具的支援方面，Sonar 不僅提供了對 ​

​IDE​

​ 的支援，可以在 ​

​Eclipse​

​和 ​

​IntelliJ IDEA​

​ 這些工具裡聯機檢視結果；同時 Sonar 還對大量的持續內建工具提供了接口支援，可以很友善地在持續內建中使用 Sonar。

此外，Sonar 的插件還可以對 ​

​Java​

​ 以外的其他程式設計語言提供支援，對國際化以及報告文檔化也有良好的支援。

名詞解釋

詳見: ​​https://docs.sonarqube.org/latest/user-guide/rules/​​

• Code Smell (Maintainability domain)
• Bug (Reliability domain)
• Vulnerability (Security domain)
• Security Hotspot (Security domain)

概念	定義
快照	在給定時間針對給定項目的一組衡量和問題。每次分析都會生成一個快照。
衡量	給定檔案或項目在給定時間的路徑成本。例如，MyClass上有125行代碼覆寫到了，或者project myProject上有30.5%的重複行密度
問題	當一段代碼不符合規則時，快照上會記錄一個問題。問題可以記錄在源檔案或單元測試檔案中。有 3 種類型的問題：Bug、代碼異味和漏洞
Bug	An issue that represents something wrong in the code. If this has not broken yet, it will, and probably at the worst possible moment. This needs to be fixed. Yesterday.
代碼氣味	代碼中與可維護性相關的問題。保持原樣意味着維護人員最多會比他們對代碼進行更改更難。最壞的情況是，他們會對代碼的狀态感到困惑，以至于在進行更改時會引入額外的錯誤。
漏洞	漏洞是影響應用程式安全性的問題，需要立即修複。
安全熱點	安全熱點是一段對安全敏感的代碼，它會突出顯示，但不一定會影響整個應用程式的安全性。由開發人員檢查代碼，以确定是否需要修複程式來保護代碼。(Code Review時确認是否需要修複)
新代碼	從上次檢查後的增量代碼
規則	應遵循的編碼标準或實踐。不遵守編碼規則會導緻錯誤、漏洞、安全熱點和代碼異味。規則可以檢查代碼檔案或單元測試的品質。
修複成本	修複漏洞和可靠性問題所需的估計時間。
技術債務	修複所有可維護性問題/代碼異味所需的估計時間
活動趨勢

本地安裝Sonar插件

官網推薦的系統內建方式

1. 開發人員的代碼在自己的IDE和使用SonarLint運作局部分析。
2. 開發人員推他們的代碼到自己喜愛的供應鍊管理：GIT，SVN......
3. 持續內建伺服器觸發自動建構和SonarQube掃描器的運作SonarQube分析所需的執行。
4. 分析報告被發送到SonarQube伺服器進行處理。
5. SonarQube伺服器處理和存儲分析報告導緻SonarQube資料庫，并顯示結果在UI中。
6. 開發者稽核，評論，挑戰他們的管理，并通過SonarQube UI減少他們的技術債務問題。
7. 開發經理收到分析報告。 OPS使用API從SonarQube自動化配置和提取資料。 OPS使用JMX來監控SonarQube伺服器。

Q&A

1. 一個項目分析哪個分支，是不是隻能管理者來控制，如果多個開發者在開發多個分支，想各自對不同的分支來分析，該怎麼做？
2. 現在的送出分析的機制是什麼樣子的？
3. 送出成功後有沒有通知機制？
4. 單元測試的覆寫率該如何內建到SonarQube上？
5. 有沒有對于那些對業務無實際壞影響的代碼，在sonar中能不能定制化規則，把這些異味或者顯示修改的地方去掉