用SonarQube來監控SoftwareQuality-2-解讀

在前一篇[簡介]中,大致說明了SonarQube在軟體品質活動中的好處,本篇將繼續說明如何解讀。(SonarQube更版頻率頗高,以下畫面以 SonarQube  6.2版為例)

【專案總覽】進到專案畫面後,首先會看到的是專案整體狀況,主要有以下5個部份

  • 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上課的簡報哦~

 

 

 

作者: 刀疤叔愛牽拖

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

發表迴響

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