用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 可以怎麼解讀。

作者: 刀疤叔愛牽拖

刀疤-英勇的勳章 牽拖-小強的剋星 -刀疤叔愛牽拖-

發表迴響

你的電子郵件位址並不會被公開。 必要欄位標記為 *