More than 1 year has passed since last update.

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

Last updated at 2023-03-26Posted at 2023-03-26

この記事では、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; }
}