用SonarQube來監控SoftwareQuality-2-解讀

在前一篇[簡介]中，大致說明了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有興趣，可以參考David上課的簡報哦～