SonarQube技术债务管理与质量门

Question

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

然而，整体质量门应该以某种方式（数学上？）遵循一定的比例。

问：鉴于上述放宽，如何计算最合适的技术债务门槛？

从一篇旧文章（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)

Answer 1

质量门由一组条件组成。您的条件列表远远长于默认质量门中的条件。您列出的大多数条件都不在默认质量门中。相反，看起来好像您已经编辑了许多规则的默认阈值。

从某种意义上说，你说的是苹果和橘子。

技术债务门槛可以包括在质量门中，但默认情况下不包括。相反，新代码上的技术债务比率包含在默认QG中。但是技术负债率的概念确实与你的问题有关。如果您在质量门中对技术债务设置一个硬门槛，小项目将比大项目更容易通过QG。如果您转而使用技术债务比率或新代码上的技术债务比率（推荐），那么您将质量门设置在基于代码基础大小和技术债务的比率上。所以每个项目都有同样的机会通过或失败。公式是这样的：