使用 SonarQube 和 Visual Studio 减轻技术债

来自 SonarSource 的 Olivier Gaudin 与来自微软的 Stuart Kent 在本周举行的 Build 大会上为听众介绍了使用 SonarQube 所带来的益处，以及如何让它更方便地为.NET 开发者所用。Kent began 在演讲的开始描述了技术债的累积所带来的沉重负担。当某个项目的开发过程结束之后，此时的技术债只是会分散实现新功能的注意力而已，但随着时间的推移，开发团队经常会发现他们的所有时间都消耗在处理技术债上了。

Gaudin 在这个背景下介绍了如何衡量代码的质量与技术债的技巧。在分析代码库时，有一种非正式的衡量指标叫做每分钟飙脏话的次数。他为我们描述了技术债的出现是由于开发者这 7 种致命的原罪所造成的：

1. 重复
2. 糟糕的复杂性分布
3. 意大利面式设计风格
4. 缺少单元测试
5. 缺乏代码标准
6. 潜在的 bug
7. 注释不足或过多，或者干脆不正确（单元测试对这种类型的 bug 无能为力）

Gaudin 表示，当项目已经开始运行之后，再回过头去实现某种试图缓解技术债的策略是非常困难的。有许多原因会让团队感觉实现这一点过于困难，包括缺乏自主性（在 QA 与开发者之间，谁应当对质量拥有自主权呢）、多样化的需求以及质量门。为了“改变游戏规则”，Gaudin 提出了以下几条建议：

• 让开发团队拥有质量的自主权
• 缩短反馈循环
• 统一质量门
• 成本并不重要
• 这很有趣！

为了对实现目标起到帮助，应当尽量缩短反馈循环，让开发团队能够第一时间获得反馈。对于现有的软件来说，重要的是不要让问题变得更糟了，因此首先要改进正在编写的新代码的质量，然后再去处理遗留代码中的问题。

SonarQube 为开发者提供了一种描述代码库的仪表板，其中提供了多种实用的指标。例如某些仪表板上的 widget 就提供了处于监控中的项目的代码行数和代码覆盖率，此外还包括单元测试覆盖率和这些单元测试的通过率。它还能够对新编写的代码进行分离式的代码覆盖率检查，而不会受现有代码库的影响，因此团队就能够确保他们所编写的新代码不会使质量继续下降。

SonarQube 从用户那里获得的反馈是，虽然这一工具在 Java 项目上表现很好，但它并不符合 C#的风格。因此 SonarQube 联系了微软，希望得到一些优秀 C#开发者的帮助。Kent 表示，虽然代码质量数据非常实用，但一上来就面对大量的指标（代码分析、克隆、代码指标等等）会让人感到喘不过气。他建议使用者创建一个质量简报，对显示哪些数据进行过滤、建立基线、设立质量门、并设立一种补救政策，从而得到一个经过精练的问题列表，让它帮助你避免、或至少是减少你被过多的工作压垮的机会。

虽然还有一部分工作还在进行中，但新版本已经可以在 TFS2013 中使用了，有兴趣的开发者可以尝试一下。要了解更多的细节，请参考Stuart Kent 撰写的关于使用SonarQube 整合MSBuild 与Team Build 的文章。

查看英文原文： Reducing Technical Debt with SonarQube and Visual Studio