使用 SonarQube 和 Visual Studio 减轻技术债

  • Jeff Martin
  • 邵思华

2015 年 5 月 6 日

话题:.NET语言 & 开发

来自 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

.NET语言 & 开发