技术债务公式没有考虑复杂性

Question

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

在复杂的代码中，补救的成本比在简单的代码中要难得多。这是一个post，在这里你可以看到和比较两个相似的项目，基于大小具有相似的技术债务，但基于复杂性具有非常不同的技术债务。此外，覆盖率正在影响这一度量；我认为，当您有足够的测试和覆盖率来确保您没有破坏任何东西时，修改代码会更容易。

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

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

但是补救成本是在每个规则上配置的固定时间，不是吗？因此，它独立于您在代码中发现的复杂性。

这是一个图像，您可以在其中看到如何在版本5.1.2中做到这一点：Technical debt with complexity

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

如果没有，这是否在您的路线图中？您是否有任何复杂性或覆盖率不会影响补救成本的参考资料？

提前谢谢。

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

Answer 1

SonarQube 5.6引入了SonarQube质量模型，该模型由错误、漏洞和代码嗅觉组成。对于Code Smells，技术债务被认为是重要的指标。对于Bugs和漏洞，它是最严重的。

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

Answer 2

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

integrated in the SonarQube system.

• It
• It计算可能存在的代码问题使您可以轻松地为每个问题提供formulas that estimates technical-debt (补救成本)

有了NDepend a code rule is a C# LINQ query，它可以嵌入一个公式来估计补救成本，也可以嵌入一个公式来估计年利率(每年不修复问题的成本，换句话说，它的业务影响)。通过阈值从年度利息估计中估计问题的严重性

例如，如果您希望有一个代码规则，该规则警告测试未很好地涵盖的复杂方法，并提供自定义和实际债务和年度利息估计，则该规则可能如下所示：

// <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工作