LoginSignup
0

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

Last updated at Posted at 2023-03-26

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

イントロダクション

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

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

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

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

NDependとは

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

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

ソースコードの分析

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

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

image.png

ベースラインの設定

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

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

image.png

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

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

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

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

image.png

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

image.png

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

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

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

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

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

image.png

フィールドに起因する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など他のメトリクスの改善も可視化されています。

image.png

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

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

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

image.png

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

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

image.png

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

image.png

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

v2.0
private class Config {

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

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

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

image.png

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

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

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

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

image.png

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

image.png

まとめ

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

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

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

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

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

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
What you can do with signing up
0