什么影响Sonarqube的可维护性结果？

Question

我遇到了一个巨大的“意大利面条代码”，缺乏文档，缺乏测试覆盖，高度复杂，缺乏设计规则等等。我让代码通过默认的声纳扫描进行分析，令我惊讶的是，维护成绩非常高，技术债务为1,1％！现实表明，几乎每个变化都会引入新的错误

我非常困惑，并且想知道实现中的一些特殊性是否可以解释这个分数...我们有很多接口（感觉4-5接口为1个实现），使用反射和服务定位器模式

是否还有其他可以使用的指标最终会对提高质量更有意义？

Answer 1

可维护性评级是修复代码库中所有类型Code Smell问题的估计时间与编写当前状态代码的估计时间的乘积。

您还应该查看代码库中的错误和漏洞。

关于你的具体要点（假设我们正在讨论Java）：

• 已知缺少文档 - 默认配置文件中有一条规则可以查找Javadoc。您可以阅读其描述和参数值，以查看它找不到的内容。
• 缺乏测试覆盖率 - 此检测中目前存在“漏洞”;如果某个类的没有覆盖范围，则在计算可以/应该覆盖的行时，不考虑该类，因此在计算覆盖率百分比时。它应该“很快”修复。第一步将出现在6.2的平台端，但需要随附的语言插件更改才能生效。
• 高度复杂 - 有规则。如果他们没有找到你认为他们应该的东西，那么看看他们的（可调）门槛。
• 缺乏设计规则 - 可能解决此问题的唯一规则（建筑约束）是
  1. 弃用
  2. 计划删除
  默认情况下
  3. 未启用从插件的最新版本中删除
• 使用反射 - 目前没有可用于检测此
的规则