使用 Quality Gate 的 SonarQube 技术债务管理
SonarQube Technical Debt management with Quality Gate
配置自定义Quality Gate,默认的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 中。但是技术债务比率的概念确实与您的问题有关。如果您在质量门中设置技术债务的硬门槛,小项目将比大项目更容易通过 QG。如果您改为使用技术债务比率或新代码的技术债务比率(推荐),那么您将根据代码库大小与技术债务的比率设置质量门。所以每个项目都有相同的机会通过或失败。公式是这样的:
Remediation cost / (Cost to develop 1 line of code * Number of lines of code)
估计线路开发成本为 30 分钟。这个值是可编辑的,顺便说一句:Administration > Technical Debt > Development cost
默认质量门包括新代码错误阈值 5 的技术债务比率。
配置自定义Quality Gate,默认的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 中。但是技术债务比率的概念确实与您的问题有关。如果您在质量门中设置技术债务的硬门槛,小项目将比大项目更容易通过 QG。如果您改为使用技术债务比率或新代码的技术债务比率(推荐),那么您将根据代码库大小与技术债务的比率设置质量门。所以每个项目都有相同的机会通过或失败。公式是这样的:
Remediation cost / (Cost to develop 1 line of code * Number of lines of code)
估计线路开发成本为 30 分钟。这个值是可编辑的,顺便说一句:Administration > Technical Debt > Development cost
默认质量门包括新代码错误阈值 5 的技术债务比率。