用SonarQube來監控SoftwareQuality-1-簡介

軟體品質是一種很玄的東西，之前沒太多量化的數據，大家好像都是憑感覺。一直到了公司推動CMMI，開始訂了一些收集品質數據的指標：如 Defect Density, Residual Defect Density, Defect Removal Efficiency, Review Efficiency, Testing Efficiency，MA團隊的MTTR(Mean time to recovery), MTBF(Mean Time Between Failures) ...等，大家才開始知道應該要用數字來量化軟體品質，也才知道數字會說話。既然數字會說話，那為什麼上述的這些指標後來就漸漸被人淡忘了？相信近幾年才進公司的員工可能甚至沒聽過這些指標。

【數字會說話，但準備這些數字累死人】
原來這些指標立意良善，只是在收集的過程中相當耗人力，久而久之就會有變(懶)通(得)作(執)法(行)。以Review Efficiency為例，光一個Code Review的checklist item就有近100條，每次code review 要用這些checklist item 逐條去檢查程式碼，老實說不太容易落實，更何況是要再填問題單記錄，等工程師改完後要走一遍相同的程序。可想而知這樣收集到的數據可能都不太完整，而在這樣基礎上就不太容易聽到真話，也因此這些數字的參考性就降低，最後被摒棄。

【自動化收集，數字才能客觀的說真話】
這幾年使用 SonarQube 搭配 Jenkins 來取代人工檢查程式的使用經驗，先從內部支援專案開始做起，發現這樣的機制至少有三個好處：

1. 完整：檢查規則近千條，比原本檢查表的100+條還多。
2. 全面：除非特別去排除，否則每個檔案都不放過，比原本抽樣檢查來得全面。
3. 持續：定期掃描，可以持續追蹤問題處理狀況。

(目前可以檢查的Language有 Java, C#, JavaScript, Web)

不僅如此，從試行的專案成員回饋中也發現：

1. 開發初期就檢查出問題，及早把寫程式習慣養成，避免錯誤的習慣一直寫下去，也可以省下之後再回來改程式的重工。
2. 不但找出問題，還說明為什麼這樣會有問題，應該改成什麼寫法，就像是工程師的隨身小老師。
3. 提供了圖形化的指標，方便 team leader 掌握品質，防微杜漸。

寫了這麼多，下一篇將以 team leader 角度來分享 SonarQube 可以怎麼解讀。