配置自定义质量门，默认的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，但仍然不在上述变量的粒度级别，在这种情况下也没有用。
答案 0 :(得分：5)
质量门由一组条件组成。您的条件列表远远超过默认质量门中的条件列表。您列出的大多数条件都不在默认质量门中。它看起来好像你编辑了许多规则的默认阈值。
从某种意义上说，你在谈论苹果和橘子。
技术债务阈值可以包含在质量门中，但默认情况下不包含。相反，新代码的技术债务比率包含在默认QG中。但技术债务比率的概念确实与您的问题有关。如果您在质量门户中设置技术债务的硬阈值，那么小项目将比通过大型项目更容易通过QG。如果您使用技术债务比率或新代码的技术债务比率（推荐），那么您将根据代码基数大小与技术债务的比率设置质量门。所以每个项目都有相同的传球或失败机会。公式如下：
估计线路开发成本为30分钟。此值可编辑，BTW：管理＆gt;技术债务＆gt;开发成本补救成本/（开发1行代码的成本*代码行数）
默认质量门包括新代码错误阈值为5的技术债务比率。