使用 SonarQube 追蹤代碼問題

越來越多的組織正在實施 DevOps 以便在通過中間開發和測試環境以後更快更好的將新代碼引入到生產環境。雖然版本控制、持續集成和部署以及自動化測試都屬於 DevOps 的範疇，但仍然存在一個關鍵問題：組織如何量化代碼質量，而不僅僅是部署的速度？

SonarQube 是用來填補這個空隙的一種選擇。它是一個開源平台，通過代碼的自動化靜態分析不斷的檢查代碼質量。 SonarQube 支持 20 多種語言的分析，並在各種類型的項目中輸出和存儲問題。

SonarQube 同時也提供了一個可同時維護和管理不同項目、不同代碼的集中的環境。可以為每個項目定製規則。持續的檢查和分析代碼的健康軌跡。

SonarQube 還可以集成到可持續集成和開發（CI/CD）流程中，協助和自動確定代碼是否為生產環境做好了準備的過程。

它可以衡量什麼

開箱即用，SonarQube 可以測量的關鍵指標，包括代碼錯誤、 代碼異味 code smells 、安全漏洞和重複的代碼。

• 代碼錯誤 是代碼中的一部分不正確或無法正常運行、可能會導致錯誤的結果，是指那些在代碼發布到生產環境之前應該被修復的明顯的錯誤。
• 代碼異味 不同於代碼錯誤，被檢測到的代碼是可能能正確執行並符合預期。然而，它不容易被修復，也不能被單元測試覆蓋，卻可能會導致一些未知的錯誤，或是一些其它的問題。從長期的可維護性來講，立即修復代碼異味是明智之舉。通常在編寫代碼的時候，代碼異味並不容易被發現，而 SonarQube 的靜態分析是一種發現它們的很好的方式。
• 安全漏洞 正如聽起來的一樣：指的是現在的代碼中可能存在的安全問題的缺陷。這些缺陷應該立即修復來防止黑客利用它們。
• 重複的代碼 也和聽起來的一樣：指的是源代碼中重複的部分。代碼重複在軟體設計中是一種很不好的做法。總的來說，如果對一部分代碼進行更改而另一部分沒有，則會導致一些維護性的問題。例如，識別重複的代碼可以很容易的將重複的代碼打包成一個庫來重複的使用。

可自定義的選項

因為它是開源的，所以 SonarQube 鼓勵用戶開發和提供可定製的選項。目前有超過 60 個插件 可用於增強 SonarQube 開箱即用的分析功能。

大多數的插件是為了增加 SonarQube 可以分析的編程語言的數量。另一些插件可以分析一些額外的指標甚至包括一些顯示的儀錶盤視圖。實際上，如果組織需要檢查一些自定義指標，或是想要在自己的儀錶盤和以特定的方式查看分析數據，或使用 SonarQube 不支持的編程語言，則可能存在一些自定義的選項可以使用。如果你想要的功能並不支持，SonarQube 源碼的開放也為你自己開發新的功能提供了可能性。

用戶還可以定製適用於每種特定編程語言分析器的規則。通過 SonarQube 用戶界面，可以按語言和按項目選擇和取消規則。這些為特定的項目指定的規則，可以很好的在一個集中的位置維護所有的數據和配置。

為什麼它那麼重要

SonarQube 為組織提供了一個集中的位置來管理和跟蹤多個項目代碼中的問題。它還可以把持續的檢查與質量門限相結合。一旦項目分析過一次以後，更進一步的分析會參考軟體最新的修改來更新原始的統計信息，以反映最新的變化。這些跟蹤可以讓用戶看到問題解決的程度和速度。這與 「儘早發布並經常發布」不謀而合。

另外，SonarQube 可使用 可持續集成流程，比如像 Hudson 和 Jenkins 這樣的工具。這個質量門限可以很好的反映代碼的整體運行狀況，並且通過 Jenkins 等集成工具，在發布代碼到生產環境時擔任一個重要的角色。

本著 DevOps 的精神， SonarQube 可以量化代碼質量，來達到組織內部的要求。為了加快代碼生產和發布的周期，組織必須意識到它們自己的技術債務和軟體問題。通過發現這些信息， SonarQube 可以幫助組織更快的生成高質量的軟體。

想要了解更多嗎？

SonarQube 基於 GUN 通用公共許可證發布，它的源碼可以在 GitHub 上查看。越來越多的用戶對 SonarQube 的特性和功能感興趣。 Twitter 和 Google 上有活躍的社區。這些社區以及 SonarQube 博客 對任何有興趣開始和使用 SonarQube 的人有很有幫助。

via: https://opensource.com/article/17/10/sonarqube

作者：Sophie Polson 譯者：Jamkr 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive