すべての開発者は、読みやすく保守しやすく、問題やバグの少ないクリーンなコードを望んでいます。そして、この目標を達成するための魔法のソリューションはありません。各企業には独自のベストプラクティスとコーディングルールがあり、コードをクリーンに保つためのプロセスを定義しようとしています。
プロジェクトのコード品質を測定することは容易な作業ではありません。多くのツールが、多くの要因に基づいてそれを評価する独自のアルゴリズムを提供しています。
- 静的解析ツールによって検出された問題。
- コードカバレッジ。
- コードの重複。
- ドキュメント。
- 設計の欠如。
コードベース品質のおおよその全体像を提供する推定値を与えてくれるメトリクスがあります。技術的負債メトリクスです。
Wikipediaは技術的負債について簡単な説明を提供しています。
技術的負債 （ 設計負債 または コード負債とも呼ばれる）とは、「短期的に実装が容易なコードを、全体的に最良のソリューションを適用する代わりに使用した場合に生じる追加の開発作業を反映するプログラミングの概念」です。技術的負債は金銭的な負債に例えることができます。技術的負債を返済しないと、「利子」が蓄積し、後で変更を実装するのがより困難になる可能性があります。未対処の技術的負債はソフトウェアエントロピーを増大させます。技術的負債は必ずしも悪いものではなく、時には（例えば概念実証として）プロジェクトを前進させるために技術的負債が必要なこともあります。一方、一部の専門家は、「技術的負債」というメタファーは影響を軽視する傾向があり、その結果、それを修正するために必要な作業の優先順位付けが不十分になると主張しています。
理論的には、技術的負債への対処はソフトウェア品質を改善する有望な方法ですが、実際には適用するのが容易ではありません。主な課題は、 技術的負債の評価方法です。
それを評価するために使用されるツールや方法は、柔軟でカスタマイズしやすいものでなければなりません。企業は、そのコンテキストに応じてアルゴリズムを調整できる必要があります。例えば、あるチームは50行を超えるコードのメソッドを許容するかもしれませんが、別のチームは30を最大値として選ぶかもしれません。
それを評価するために使用されるツールや方法は、柔軟でカスタマイズしやすいものでなければなりません。企業は、そのコンテキストに応じてアルゴリズムを調整できる必要があります。例えば、あるチームは50行を超えるコードのメソッドを許容するかもしれませんが、別のチームは30を最大値として選ぶかもしれません。
アジャイルアルゴリズムが救いに
- 技術的負債の計算を柔軟にする方法は2つあります。
- 特定のアルゴリズムを定義し、開発チームのコンテキストに応じてそのパラメータを変更できるようにする。
特定のアルゴリズムを定義せず、ユーザーに計算式をカスタマイズする方法を提供する。 CppDepend では、アルゴリズムを柔軟にすることを選択しました。プロジェクトのコンテキストに応じて、ルールごとに調整できます。
例えば、大きすぎる型によってもたらされる負債の計算式は次のとおりです。
そして、Cppcheckの問題に対する別の計算式は次のとおりです。
この方法で、各チームはプロジェクトのコンテキストに基づいて負債計算を設定でき、負債計算の推定誤差を減らすのに役立ちます。
ベースラインとの比較
技術的負債の評価は困難です。すべてのアルゴリズムは推定誤差をもたらし、その結果は多くの要因に依存するため、調整には時間がかかる可能性があります。
しかし、コードベースの2つのイテレーションの技術的負債を比較すれば、そのコード品質がどのように進化しているかをよく把握できます。
2つのバージョンの負債メトリクスの差は、推定誤差を最小限に抑え、より正確な負債メトリクスを提供します。
トレンドを使用した品質の進化の追跡
技術的負債のような概念はかなり役立ちます。しかし、視覚的なものほど心に響くものはありません。
例えば、メソッドあたりの平均循環的複雑度やコード行数を見たいかもしれません。一般的に言えば、コードベースではこれらの数値は比較的平坦（かつ低く）保たれることが期待されます。トレンドチャートを使用してこれを確認し、監視することができます。
トレンドラインは、時折小さな上昇や下降があるものの、ほぼ平坦に保たれていますか？それとも、ゆっくりと着実に上昇していますか？このようなトレンドを観察することで、問題を通常よりもはるかに早く発見するのに役立ちます。ひどいメソッドの複雑さを持つコードベースを見るたびに、誰かが午後のひとときでそうしたわけではないことがわかります。それは、全体的で緩やかなトレンドに何年も気づかなかった結果なのです。
結論
技術的負債メトリクスは、コードベース品質を監視する強力な方法です。ただし、ユーザーはそれを調整し推定誤差を減らすための簡単な方法を必要としています。そして、絶対的な負債の値自体よりも、技術的負債がどのように進化するかに焦点を当てる方が有益です。