0

カスタム クオリティ ゲートを構成すると、デフォルトの 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 からそれよりも小さい数に強制する必要があります。これは確かに合理的です。いくつかのルールを緩和すると、制御された技術的負債のマージンが増え、制御されていない技術的負債の累積日数のしきい値が短くなります。

ただし、全体的な品質ゲートは、何らかの形で (数学的に?) 一定の比率に従う必要があります。

質問: 上記の緩和を考慮して、最も適切な技術的負債のしきい値を計算する方法は?

古い記事(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)

注:\読みやすくするために追加されました。

ただし、適切な計算を行うには未知の変数が多すぎますが、上記のすべての品質ゲート項目をカバーしているわけではありません (これも古いリファレンスです)。

他のより最近の情報源は、関連する項目について詳細に説明していますが、比例した方法で値を調整する方法については説明していません。

( Admin / Configuration / Technical Debtsonar.technicalDebt.developmentCost )のデフォルト値は30分です。これは、1 LOC (1 行のコードを開発するためのコスト) = 30 を意味しますが、上記の変数の粒度レベルではなく、この場合には役に立ちません。

4

1 に答える 1

5

クオリティ ゲートは、一連の条件で構成されます。条件のリストは、デフォルトの品質ゲートのリストよりもはるかに長くなっています。リストする条件のほとんどは、デフォルトの品質ゲートにはありません。代わりに、多数のルールのデフォルトのしきい値を編集したように見えます。

ある意味では、あなたはリンゴとオレンジについて話している.

技術的負債のしきい値を Quality Gate に含めることができますが、デフォルトでは含まれていません。代わりに、新しいコードの技術的負債比率がデフォルトの QG に含まれています。しかし、技術的負債比率の概念は、あなたの質問に関係しています。品質ゲートで技術的負債に厳しいしきい値を設定すると、小規模なプロジェクトは大規模なプロジェクトよりも簡単に QG を通過できます。代わりに、技術的負債比率または新しいコードの技術的負債比率を使用する場合 (推奨)、コード ベースのサイズと技術的負債に基づく比率で品質ゲートを設定します。したがって、すべてのプロジェクトが成功または失敗する可能性は同じです。式は次のとおりです。

修正コスト / (コード 1 行の開発コスト * コード行数)

で、推定ライン開発コストは 30 分です。この値は編集可能です。ところで:管理 > 技術的負債 > 開発コスト

デフォルトの品質ゲートには、5 の新しいコード エラーしきい値の技術的負債比率が含まれます。

于 2016-09-19T21:08:33.123 に答える