Wikipediaでは、技術的負債について簡潔な説明が提供されています。
技術的負債 （ 設計負債[1] または コード負債とも呼ばれます）は、「全体的に最適な解決策を適用する代わりに、短期的に実装しやすいコードを使用した結果として発生する追加の開発作業を反映する、プログラミングにおける概念」です。[2]技術的負債は、金銭的な 負債。[3] 技術的負債を返済しないと、「利子」が蓄積し、後で変更を実装するのが難しくなる可能性があります。対処されない技術的負債は、 ソフトウェアエントロピーを増大させます。技術的負債は必ずしも悪いものではなく、場合によっては（たとえば概念実証として）プロジェクトを前進させるために必要になることもあります。一方、「技術的負債」という比喩は影響を軽く見せがちであり、その結果、修正に必要な作業の優先順位付けが不十分になると主張する専門家もいます。[4][5]
理論上、技術的負債への対処はソフトウェア品質の改善に非常に有望ですが、実際にこの指標を使うのは容易ではありません。実際、大きな課題は 技術的負債をどう評価するか。
多くのツールが、複数の要因に基づいて技術的負債を評価する独自のアルゴリズムを提供しています。
- 静的解析ツールによって検出された問題。
- コードカバレッジ。
- コードの重複。
- ドキュメント。
- 設計の欠如。
技術的負債の評価にどのツールや方法を使う場合でも、計算は柔軟でカスタマイズしやすいものでなければなりません。各組織が、自らのコンテキストに応じてアルゴリズムを調整できる必要があります。
アジャイルなアルゴリズム
負債計算を柔軟にする方法は2つあります。
- 特定のアルゴリズムを定義し、開発チームのコンテキストに応じてパラメータを調整できるようにする。
- 固定のアルゴリズムを定義せず、ユーザーが計算式をカスタマイズできる方法を提供する。
With CppDependでは、アルゴリズムを非常に柔軟にする方法を選び、プロジェクトのコンテキストに応じてルールごとに変更できるようにしています。
たとえば、大きすぎる型によって発生する負債の計算式は次のとおりです。
次に、Cppcheckの問題に対する別の計算式を示します。
このようにして、各チームはプロジェクトのコンテキストに応じて負債計算を設定し、推定誤差を減らせます。
ベースラインとの比較
技術的負債を正確に評価するのは困難です。どのアルゴリズムにも多少の推定誤差があり、計算は多くの要因に依存するため、徹底的に調整するには時間がかかることがあります。
しかし、コードベースの2つのバージョン間で技術的負債を比較すれば、コード品質がどのように変化しているかを示す良い指標になります。
2つのバージョン間で負債メトリクスを比較することで、推定誤差を最小限に抑え、変化をより意味のある形で測定できます。
まとめ
技術的負債は、コードベース品質を監視するための強力なメトリクスです。ただし、ユーザーには計算を調整して推定誤差を減らす簡単な方法が必要です。実際には、絶対値自体に注目するよりも、技術的負債が時間とともにどう変化しているかを追跡する方が有用なことが多いです。