使用 SonarQube 追蹤程式碼問題

通過不斷分析程式碼以了解潛在的品質問題，開源的 SonarQube 專案支援了 DevOps 的“儘早發布和經常發布” 的思維模式。

越來越多的組織正在實施 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 的人有很有幫助。