技術管理者---提升研發程式碼質量---程式碼檢查工具Sonar
本文是《技術管理者---提升研發程式碼質量》系列文章第二篇，第一篇整體介紹請看博文《技術管理者---提升研發程式碼質量---總體方法論》。本文重點講三部分內容：1）sonar是什麼，研發體系如何利用sonar提供程式碼質量；2）開發過程中如何使用Sonar保證程式碼質量；3）sonar與Jenkins持續整合，持續閉環研發程式碼質量。
Sonar是什麼？能幹什麼？
Sonar是一個用於程式碼質量管理的開源平臺，用於管理原始碼的質量 通過外掛形式，可以支援包括java,C#,C/C++等多種程式語言的程式碼質量管理與檢測。Sonar可以從以下7個維度檢測程式碼質量：
- 不遵循程式碼標準：包含CheckStyle,Findbugs等等程式碼規則檢測工具
- 潛在的缺陷：包含CheckStyle,Findbugs等等程式碼規則檢測工具
- 糟糕的複雜度分佈：檢查過高複雜度的檔案、類、方法
- 重複：重複程式碼檢查
- 註釋不足或者過多：
- 缺乏單元測試：
- 糟糕的設計：找出包與包、類與類之間相互依賴關係
先放幾個Sonar能發現的問題常見問題程式碼截圖：
能夠發現Sonar檢測出很多研發質量不規範、非常容易出錯的地方，作為研發管理者你肯定會想：這麼好的工具，我們研發團隊一定要使用起來。 這種想法非常好，但一個更關鍵的問題是：研發團隊如何使用Sonar，如何和現有研發流程規範結合起來，這就需要將Sonar檢測結果作為現有研發流程中的重要一環，才能讓Sonar長期發揮作用。 不然只會出現如下的情況：研發經理說下個版本開始我們使用Sonar檢測程式碼啊，只有檢測通過了才行。 相信我，過2個月之後，你將發現沒人按照你說的去執行。
要想讓Sonar與現有研發流程緊密結合、提升研發質量，我們先來了解一下Sonar家族體系。
然後再來看看Sonar報告發現問題的種類
最後來看作為技術管理者，如何將Sonar作用在研發流程與持續整合環境當中
PS：上面講解的研發流程維度使用Sonar的方式需要人的參與，不是最好的方案，最好的方案是開發人員在提交程式碼到Git的時候，自動觸發Sonar增量檢測，並能將錯誤資訊返回到Git提交客戶端，這種方案需要修改Git客戶端與伺服器端邏輯，代價太大了。目前業界有一種Sonar+Gerrit配合使用，能夠達到上面的效果，只是使用Gerrit的代價也較大，需要同步Gerrit與GitLab的倉庫、同步賬號、同步許可權等一系列的同步，非常容易因為同步不成功而導致整個程式碼提交、打包產生問題。故博主所在公司使用上圖中的方案。
下面講解如上研發體系使用Sonar做靜態程式碼檢測的兩種整合方案，詳細的實施方案。
開發過程中如何使用Sonar保證程式碼質量
Idea開發中安裝Sonar外掛《SonarLint-3.4.0.2532.zip》，選單路徑“Idea-->File-->Setting-->Plugins-->Install plugin from disk”，截圖如下
安裝完成之後，重啟Idea，就能看到當前開啟檔案的檢查報告結果，如下：
點選右側Report，可以檢查整個工程Sonar掃描結果
這樣每位開發同學在提交程式碼前都會將本次任務裡涉及到的程式碼做Sonar靜態檢查，檢查通過後截圖到自測報告中，完成的規範與研發流程強關聯。
Sonar與Jenkins持續整合，持續閉環研發程式碼質量(安裝Jenkins、SonarQube，並整合服務每天出自檢報告)
安裝Jenkins，網路上有很多安裝Jenkins的完整文章，讀者可以直接參照，本博文裡面就不詳細介紹了，可以參考：《https://blog.csdn.net/sms15732621690/article/details/71336224》
安裝SonarQube服務，網路上也有很多完成的文章，讀者可以直接參照，本博文裡面就不詳細介紹了，可以參考：《https://www.cnblogs.com/ding2016/p/8065241.html》。
這裡面有幾個坑特別要注意：
- 要想執行SonarQube，作業系統至少要有2G空閒記憶體，不然服務可能會無緣無故的程序沒有，特徵如下：
2018.09.06 17:11:31 INFO app[][o.s.a.SchedulerImpl] Process[ce] is up
2018.09.06 17:11:31 INFO app[][o.s.a.SchedulerImpl] SonarQube is up
2018.09.06 17:26:39 WARN app[][o.s.a.p.AbstractProcessMonitor] Process exited with exit value [es]: 137
2018.09.06 17:26:39 INFO app[][o.s.a.SchedulerImpl] Process [es] is stopped
- 啟動好SonarQube的時候，切記把token記錄下來，後面在和Jenkins整合的時候需要。
下面介紹Jenkins與SonarQube的整合方式，根據官方文件《https://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Scanner+for+Jenkins#AnalyzingwithSonarQubeScannerforJenkins-AnalyzingwiththeSonarQubeScanner》介紹，整合方式4種方式。 博主所在企業實用第一種“Analyzing with the SonarQube Scanner”，大部分的網際網路企業，應該是採用第三種” Analyzing with SonarQube Scanner for Maven or Gradle”。下面詳細介紹第一種整合方式詳細配置過程(也可以先看官方文件做了解)。
- 配置Jenkins系統管理--->外掛管理--->安裝”SonarQube Scanner for Jenkins”(如下),安裝成功後重啟Jenkins
- 配置Jenkins系統管理--->系統設定--->配置” SonarQube servers”(如下),注意這裡需要應用前面安裝SonarQube的Token。 其他的配置正常進行(Java、Git等)
- 新建“構建一個自由風格的軟體專案”任務，分別配置好“GitHub”、”原始碼管理”、”構建觸發器”,”構建環境”,”構建型別Execute SonarQube Scanner”分別截圖如下：
上面的sonar.sources用於設定專案的原始碼地址，一般實際專案上，原始碼都是在很多子工程的，所以這裡需要寫多個，多個原始碼地址用,號隔開，路徑可以使用相對路徑。
- 配置完成後點選”立刻構建”構建成功後即可看到結果，可在Jenkins中快速連結到SonarQube中的結果。截圖如下：
至此，大功告成，讓此靜態檢查持續整合方法，提升你們團隊的 程式碼質量吧。