使用SonarQube和Visual Studio減輕技術債
英文原文：Reducing Technical Debt with SonarQube and Visual Studio
來自 SonarSource 的 Olivier Gaudin 與來自微軟的 Stuart Kent 在本周舉行的 Build 大會上為聽眾介紹了使用 SonarQube 所帶來的益處，以及如何讓它更方便地為 .NET 開發者所用。Kent began 在演講的開始描述了技術債的累積所帶來的沉重負擔。當某個項目的開發過程結束之后，此時的技術債只是會分散實現新功能的注意力而已，但隨著時間的推移，開發團隊經常會發現他們的所有時間都消耗在處理技術債上了。
Gaudin 在這個背景下介紹了如何衡量代碼的質量與技術債的技巧。在分析代碼庫時，有一種非正式的衡量指標叫做每分鐘飆臟話的次數。他為我們描述了技術債的出現是由于開發者這 7 種致命的原罪所造成的：
- 重復
- 糟糕的復雜性分布
- 意大利面式設計風格
- 缺少單元測試
- 缺乏代碼標準
- 潛在的 bug
- 注釋不足或過多，或者干脆不正確（單元測試對這種類型的 bug 無能為力）
Gaudin 表示，當項目已經開始運行之后，再回過頭去實現某種試圖緩解技術債的策略是非常困難的。有許多原因會讓團隊感覺實現這一點過于困難，包括缺乏自主性（在 QA 與開發者之間，誰應當對質量擁有自主權呢）、多樣化的需求以及質量門。為了“改變游戲規則”，Gaudin 提出了以下幾條建議：
- 讓開發團隊擁有質量的自主權
- 縮短反饋循環
- 統一質量門
- 成本并不重要
- 這很有趣！
為了對實現目標起到幫助，應當盡量縮短反饋循環，讓開發團隊能夠第一時間獲得反饋。對于現有的軟件來說，重要的是不要讓問題變得更糟了，因此首先要改進正在編寫的新代碼的質量，然后再去處理遺留代碼中的問題。
SonarQube 為開發者提供了一種描述代碼庫的儀表板，其中提供了多種實用的指標。例如某些儀表板上的 widget 就提供了處于監控中的項目的代碼行數和代碼覆蓋率，此外還包括單元測試覆蓋率和這些單元測試的通過率。它還能夠對新編寫的代碼進行分離式的代碼覆蓋率檢 查，而不會受現有代碼庫的影響，因此團隊就能夠確保他們所編寫的新代碼不會使質量繼續下降。
SonarQube 從用戶那里獲得的反饋是，雖然這一工具在 Java 項目上表現很好，但它并不符合 C# 的風格。因此 SonarQube 聯系了微軟，希望得到一些優秀 C# 開發者的幫助。Kent 表示，雖然代碼質量數據非常實用，但一上來就面對大量的指標（代碼分析、克隆、代碼指標等等）會讓人感到喘不過氣。他建議使用者創建一個質量簡報，對顯示 哪些數據進行過濾、建立基線、設立質量門、并設立一種補救政策，從而得到一個經過精練的問題列表，讓它幫助你避免、或至少是減少你被過多的工作壓垮的機 會。
雖然還有一部分工作還在進行中，但新版本已經可以在 TFS2013 中使用了，有興趣的開發者可以嘗試一下。要了解更多的細節，請參考 Stuart Kent 撰寫的關于使用 SonarQube 整合 MSBuild 與 Team Build 的文章。