转载

使用SonarQube和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的文章。

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

正文到此结束