配置自定义质量门后，默认的SonarQube Way已作为初始参考，并进行了进一步调整和自定义（添加了更多检查）。我们当前的质量门如下所示（旧版本与当前版本）：
Blocker issues: error threshold at 0
Complexity/class: error threshold at 12
Complexity/file: error threshold at 12
Complexity/function error threshold at 2
Coverage error threshold at 100 >> changed to 65
Critical issues error threshold at 0
Duplicated lines (%) error threshold at 5
Info issues error threshold at 10
Major issues error threshold at 50
Minor issues error threshold at 100
Overall coverage error threshold at 100 >> changed to 65
Public documented API (%) error threshold at 50
Skipped Unit tests error threshold at 0
Technical Debts error threshold at 10d >> change to (?? < 10)
Unit test errors error threshold at 0
Unit test failures error threshold at 0
要点是关于技术债务天数，鉴于放宽了其他检查（复杂性和覆盖范围），应该将其从10天缩短为更短的时间。这的确是合理的：放宽某些规则，您应该拥有更多的受控技术债务保证金，从而缩短了不受控制的技术债务累积天数的阈值。
但是，总体质量门应该以某种方式（在数学上？）遵循一定的比例。
问题：鉴于上述放松，如何计算最合适的技术债务门槛？
从old article（2009年，因此很可能不再适用）中推导出以下公式：
TechDebt = (cost_to_fix_one_block * duplicated_blocks) + \
(cost_to fix_one_violation * mandatory_violations) + \
(cost_to_comment_one_API * public_undocumented_api) + \
(cost_to_cover_one_of_complexity * uncovered_complexity_by_tests) + \
(cost_to_split_a_method * function_complexity_distribution) + \
(cost_to_split_a_class * class_complexity_distribution)
注意：添加了
\以提高可读性。但是，有太多未知变量无法进行正确的计算，但是它并未涵盖上述所有质量门控项目（再次，这是一个古老的参考）。
其他最近的sources详细解释了相关的项目，但没有解释如何按比例调整值。
sonar.technicalDebt.developmentCost（管理/配置/技术债务）的默认值为30分钟，这意味着1 LOC（开发1行代码的成本）= 30，但仍不属于上述变量的粒度级别，在这个案例。 最佳答案
质量门由一组条件组成。您的条件列表远比默认质量门中的条件列表长。您列出的大多数条件都不在默认的质量门中。看起来好像您已经编辑了许多规则的默认阈值。
从某种意义上讲，您是在谈论苹果和橙子。
可以在质量门中包括技术债务阈值，但默认情况下不包括。取而代之的是，默认质量保证中包括了有关新法规的技术债务比率。但是技术债务比率的概念确实与您的问题有关。如果您在质量门口设定了严格的技术债务门槛，那么与大型项目相比，小型项目通过QG的时间会更容易。如果改为使用技术债务比率或新代码上的技术债务比率（推荐），那么您将根据代码库大小与技术债务的比率来设置质量门。因此，每个项目都有通过或失败的相同机会。公式是这样的：
修复成本/（开发1行代码的成本*行代码的数量）
估计需要30分钟的线路开发成本。该值是可编辑的，顺便说一句：管理>技术债务>开发成本
默认质量门包括新代码错误阈值为5的技术债务比率。