1

在 5.5 之前的 Sonarqube 版本中，可能会更改计算技术债务的方式以考虑复杂性，但在 5.5 之后我看不到如何更改它。您是否删除了此配置？

恕我直言，复杂代码中的修复成本比简单代码中的要困难得多。这是一篇文章，您可以在其中查看和比较两个类似项目，它们基于规模具有相似的技术债务，但基于复杂性具有完全不同的技术债务。此外，覆盖率正在影响这项措施；而且我认为当您有足够的测试和覆盖范围以确保您不会破坏任何东西时，修改代码会更容易。

在 sonarqube 文档中，用于计算技术债务比率的公式是：

Remediation cost / (Cost to develop 1 line of code * Number of lines of code)

但是补救成本是在每个规则上配置的固定时间量，不是吗？因此，它与您在代码中可以找到的复杂性无关。

这是一张图片，您可以在其中看到如何在版本 5.1.2 中完成此操作： 具有复杂性的技术债务

有没有办法在 LTS 或 6.x 版本中配置技术债务，以便像以前版本一样考虑复杂性？

如果没有，那在你的路线图中吗？您是否有任何参考表明复杂性或覆盖范围不会影响修复成本？

提前致谢。

注意：认知复杂性的新概念似乎很有趣，我们再次谈论复杂性，它会是一个很好的候选者。但是我还没有看到如何在Sonarqube 6.3.1中看到它，这可能吗？

4

2 回答 2

1

SonarQube 5.6 引入了 SonarQube 质量模型，它由错误、漏洞和代码气味组成。对于 Code Smells，技术债务被认为是重要的衡量标准。对于错误和漏洞，它是最高严重性。

在采用这种新的质量模型时，基于复杂性计算技术债务的能力确实已经下降，并且没有恢复它的计划。同时，“技术债”不再包括修复Bug和漏洞的时间；它只是代码气味。

于 2017-04-26T11:38:39.087 回答
1

由于 G.Ann 的答案解释说使用 SonarQube 不再可行，因此在 .NET 代码上，您仍然可以使用工具 NDepend。

使用 NDepend ，代码规则是一个 C# LINQ 查询，它可以嵌入一个公式来估计修复成本，也可以嵌入一个公式来估计年利息（不解决问题的每年成本，换句话说，它的业务影响） . 问题严重性是通过阈值从年度利息估算中估算出来的

例如，如果您想要一个代码规则来警告测试没有很好地覆盖的复杂方法，提供自定义和现实的债务和年利率估计，规则可以如下所示：

// <Name>Complex method must be covered by tests</Name>
warnif count > 0 
from m in Application.Methods
where m.PercentageCoverage < 80 &&
      m.CyclomaticComplexity > 10select new { 
   m,
   m.PercentageCoverage,
   m.CyclomaticComplexity,
   m.NbLinesOfCodeNotCovered,
   Debt = (10 + 3*(m.CyclomaticComplexity -10) + 4*m.NbLinesOfCodeNotCovered)
          .ToMinutes().ToDebt(),
   AnnualInterest = (20 + 2*(m.CyclomaticComplexity) + 6*m.NbLinesOfCodeNotCovered)
                    .ToMinutes().ToAnnualInterest()
}

这里我们选择简单的线性公式，但它实际上可以是任何公式，它只是针对专用于查询代码质量的代码模型运行的 C# 查询。

在 Visual Studio 中编辑的规则及其结果如下所示，这些问题和估计可以导入 SonarQube 系统：

NDepend 自定义公式来估计技术债务

免责声明：我为 NDepend 工作

于 2017-04-27T07:51:22.103 回答