リファクタリングによる技術的負債の返済をNDependで可視化してみた

この記事では、NDependを使ってどのように技術的負債を返済できるか検証した内容を紹介します。

イントロダクション

NDependの作者であるPatrick Smacchia氏からライセンスをいただきました。しかし、最近の私の役割はインフラ寄りでアプリケーション開発から離れているため、業務で使う機会がありませんでした。そこで、過去に習作したソースコードをリファクタリングしてみることにしました。

こちらが今回リファクタリングしてみたソースコードで、簡単なデスクトップキャプチャツールです。

15年前に書いたコードなので稚拙そのものですが、リファクタリングの実践にはちょうどいいと考えました。

Patrick氏に尋ねたところ「古いプロジェクトをベースラインとして設定し、リファクタリング後のプロジェクトと比較して、どの程度改善されたかを可視化する」機能がマッチするとアドバイスされました。今回はこの機能を試して、リファクタリングによる改善をどのように可視化できるかを示します。

NDependとは

NDependは、.NETコードを分析するための静的解析ツールです。主な機能には、コード品質・アーキテクチャの視覚化、コードの変更のトラッキングなどがあります。

Patrick氏がNDependについて語っている記事です。

ソースコードの分析

VisualNDepend.exeを起動してVSプロジェクトを解析します。VSプロジェクトとの紐付けはNDependのプロジェクトとして保存できます。

解析結果はダッシュボードで可視化されます。

ベースラインの設定

リファクタリングの前にベースラインを設定します。

まず、元のソースコードv1.0をコピーしv2.0を作成します。次に、v1.0/v2.0両方のNDpendプロジェクトを作成し、v2.0のベースラインとしてv1.0を設定します。

以降は、v1.0は修正せずv2.0をリファクタリングします。

ホットスポットを探索する

NDependには、リファクタリングすべき箇所の見極めを支援する強力な機能があります。

先ほどのダッシュボードのDebt（技術的負債）に着目します。

Types to Fix Priorityを選択すると、ブレークポイントの低いissueを含むクラスがリストされます。

ブレークポイントの低さはコード品質の向上において投資価値の高さを表しており、優先度を判断する指標になります。ブレークポイントの考え方については公式ドキュメントをご参照ください。

今回はブレークポイントが最も低く、かつレートがEのMainForm+Configを修正することにします。

なお、レートはSQALEに基づいています。

ホットスポットをリファクタリングする

MainForm+ConfigのIssuesをクリックすると、Issueがリストされます。

フィールドに起因するIssueが多く検出されているので、プロパティに変更します。

v1.0

/// <summary>
/// 設定
/// </summary>
private class Config {

    /// <summary>
    /// 画像の形式
    /// </summary>
    public string ImageType;

    /// <summary>
    /// 画像の倍率
    /// </summary>
    public decimal Magnification;
}

v2.0

/// <summary>
/// 設定
/// </summary>
private class Config {

    /// <summary>
    /// 画像の形式
    /// </summary>
    public string ImageType { get; set; }

    /// <summary>
    /// 画像の倍率
    /// </summary>
    public decimal Magnification { get; set; }
}

ビルド後にもう一度分析すると、ベースラインからどのくらいの負債を返済できたかがわかります。またMethod Complexityなど他のメトリクスの改善も可視化されています。

新たに負債を作りこんでいないか？

リファクタリングにより、新たに負債を生み出していないことが重要です。

先ほどのダッシュボードを再掲します。

これは、ベースラインから新たに４つのIssueが発生していることを示しています。これらは、先ほどのリファクタリングで新たに作りこんでしまった負債です。

+4をクリックすると、Issueが発生しているクラスがリストされます¹。

さらに該当クラスのtypeIssuesをクリックすると、issueを確認できます。

いずれも、MainForm+Configクラスがパブリックでないにもかかわらず、プロパティの可視性がパブリックになっていることを指摘されているので、internalに修正します。

v2.0

private class Config {

    /// <summary>
    /// 画像の形式
    /// </summary>
    internal string ImageType { get; set; }

    /// <summary>
    /// 画像の倍率
    /// </summary>
    internal decimal Magnification { get; set; }
}

ビルド後にもう一度分析を実行し、新たなIssueが解決されたことを確認します。

ベースラインとの比較を可視化する

先述の通り、ベースラインからどのくらいの負債を返済できたか比較できます。

また、他にも様々な視点で比較できます。

例えば、メニューからDiff > Code Diff Summary > Types where code was changedを選択すると、先ほどのリファクタリングで変更されたクラスがリストされます。

さらに、コンテキストメニューのDiff Sourceを選択すると、該当クラスのベースラインとの差分が表示できます。

まとめ

今回は、ベースラインとの比較を中心にNDependをどのようにコード品質の改善に活用できるか解説しました。

検証してみて、NDpendには次の効果が期待できると感じました。

• 負債による損失やリファクタリングによる返済の定量化によるビジネスサイドへの訴求効果。すなわちリファクタリングを提案する際の根拠として利用。
• コード品質向上の達成率や、目標値に対しての現在のコード品質の可視化によるデベロッパーのモチベーション向上

また、NDpendには他にも多くの機能があり、ユースケースとして紹介されています。いずれ他の機能も試してみたいと思います。

1. メニューのIssues > New Debt and Issues per Ruleでもベースラインから新たに追加されたIssueをリストできます。 ↩