用SonarQube來監控SoftwareQuality
簡介

軟體品質是一種很玄的東西，之前沒太多量化的數據，大家好像都是憑感覺。
一直到了公司推動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 來取代人工檢查程式的使用經驗，先從內部支援專案開始做起，發現這樣的機制至少有三個好處：

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


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

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

開發初期就檢查出問題，及早把寫程式習慣養成，避免錯誤的習慣一直寫下去，也可以省下之後再回來改程式的重工。
不但找出問題，還說明為什麼這樣會有問題，應該改成什麼寫法，就像是工程師的隨身小老師。
提供了圖形化的指標，方便 team leader 掌握品質，防微杜漸。
寫了這麼多，下一篇將以 team leader 角度來分享 SonarQube 可以怎麼解讀。
原文網址：http://blog.gss.com.tw/index.php/2017/04/18/sonarqube/

解讀

在用SonarQube來監控SoftwareQuality-1-簡介(https://goo.gl/wq7FQ2)中，大致說明了SonarQube在軟體品質活動中的好處，本篇將繼續說明如何解讀。(SonarQube更版頻率頗高，以下畫面以 SonarQube 6.2版為例)
【專案總覽】進到專案畫面後，首先會看到的是專案整體狀況，主要有以下５個部份


• Quality Gate：相當於對這次掃描結果的總評分，以上圖為例，說明了這次掃描和前一次掃描相比增加了8個新的弱點，而下方的紅字則是指踩到了＂新的弱點大於0″的規則。同樣的往右邊看，由於新增加了3個Bug，也踩到了”新增加的Bug大於0″的規則。
• Bugs & Vulnerabilities：以上圖為例，數字從左往右代表的意義是：目前這個案子總共有2,800+個Bugs，以及329個弱點，其中有3個Bugs 以及 8個弱點是這次掃描時新發現的。
• Code Smells：以上圖為例，數字從左往右代表的意義是：目前有相當於115天的技術債以及10,000+以上的issues, 其中這次掃描有新增了2小時的技術債和28個新issues。在左邊的數字下方也可以看到趨勢圖是逐次往下降，表示技術債雖然很多，但持續在減少中。
• Coverage：以上圖為例，數字從左往右代表的意義是：目前測試涵蓋率是0%，沒有單元測試，新增加的275行程式碼也都沒有測試程式有涵蓋到。
• Duplications：以上圖為例，數字從左往右代表的意義是：目前有12.3%的程式碼有重複，重複的Block約有1,400個，最近增加的新程式中有663行有重複。
• 以上是對整個案子的整體健檢評估的結果，想要了解每個指標的內容可以進一步點到上述的各個指標drill down 往下看。（左邊和右邊的數字都可以點）

接下來我們就要再往下看，這些掃出來的問題怎麼管理？
【Issues】：一進來後預設是看所有未解決的Issues。如果案子Issues太多，左邊提供了一些常用的篩選條件；右邊則是By 程式列出每個程式所被掃出來的問題。


【嚴重度】如果問題太多而人力不足時，可以依嚴重度將資源分配在刀口上，通常會以Blocker & Critical 為優先處理，行有餘力再往Major甚至Minor修。（不過如果專案一開始就有持續在關注，應該可以一開始就把數字控制在理想範圍）如下圖，您可以點選Blocker, Critical 來篩選這兩個嚴重度的問題。


【想知道最常出錯的 Top N】有時候我們會想知道，什麼問題是一而再的發生，日後有新成員加入時，可以避免再犯相同的錯。或是 team leader 將大家常犯的問題整理後，通知大家如何修改，日後如何避免。就可以如上圖勾選Rule 條件，看到依Rule違反次數的排名。

【Bug 是誰commit上來的】發現有bug時，都會想知道是不是自己或是誰寫的，就可以用Author這個篩選條件。不過要注意的是：這裡看到的是把程式commit到版控系統的人，所以如果全部的程式統一由某個人集中上版就會算在這個人頭上；尤其是新專案初始時，可能由一個人先去移轉產品或相似專案的程式碼過來時，移轉前未解決的問題就會算在這個人身上。(如下圖，先篩選Blocker, Critical 之後，勾選Author可看到每個人commit上來的問題)


【複合條件】這些條件都可以搭配使用，如下圖是挑選Severity為Blocker或Critical 且Language為C#的Unresolved issue


找到程式碼中此Issue的所在位置，確認這個問題的確存在，可以查看這個Issue的說明，以及Noncompliance code example和 Compliance solution。


（如果認為有些Rule有誤判，也歡迎到【SonarQube申訴討論區】討論）
以上，是從專案程序碼健檢報告一路Drill down到每一行程式碼的過程，如果對SonarQube有興趣，可以參考「軟體品質靜態分析 - SonarQube 實務」哦～

原文網址：http://blog.gss.com.tw/index.php/2017/04/21/sonarqube2/
軟體品質靜態分析 - SonarQube 實務：http://www.iiiedu.org.tw/taipei/edm/dse340.htm
SonarQube申訴討論區：http://gsskm.gss.com.tw/forum/readtopic/295



作者： 刀疤叔愛牽拖
刀疤－英勇的勳章 牽拖－小強的剋星 －刀疤叔愛牽
叡揚資訊 http://www.gss.com.tw/