私はNDependを試していて、それについてのいくつかのブログ投稿を読んでいて、ポッドキャストも聞いていました。NDepend は非常に便利なツールだと思いますが、どこで使用するかはまだわかりません。
どうやって使うんですか?使っていますか、なぜですか?なぜだめですか?
現実世界の現実的な例について聞きたいです。
過去数年間、NDepend を広範囲に使用してきました。基本的に、これは依存関係分析ツールであるため、依存関係に関連する多くの問題を解決するのに役立ちます。
私がこれを使用する主な目的の 1 つは、アセンブリ、型、およびメソッド間の依存関係を調べることです。これは、型間の結合が手に負えないかどうかを把握するのに役立ち、リファクタリングの機会を見つけるのにも役立ちます。
他のアセンブリへの型の抽出.移動など、大規模なリファクタリングに着手するとき、これにより、何が何に依存しているかを確認できるため、古い「型を別のアセンブリに移動し、コンパイルして何が壊れているかを確認する」という古い操作を行う必要がなくなります"
NDepend には、この種の情報を表示するための優れたビジュアル マトリックスもあります。
さらに、カスタム クエリを記述できる優れたクエリ言語 CQL を備えています。これらは、「このメソッドを呼び出すすべてのメソッドを表示する」などの単純なものから、デッド コードを強調するためのクエリ、循環的複雑さに関するクエリ、カップリングなど、その他多数のものです。
次に、ビルド プロセスに統合できるため、「メソッドに 100 行を超えるコードがあり、コメントがない場合はビルドを失敗させる」など、CQL クエリに基づいてビルドの警告/失敗を発生させることができます (これは例です)。 - この特定の指標が良いことだと言っているわけではありません)。
また、コード カバレッジ データをインポートして、コード カバレッジの少ない領域を視覚的に表現したり、コード カバレッジ情報に対して CQL クエリを実行したりできます (例: コード カバレッジが 70% 未満のメソッドを表示)。
プロジェクトの現在のビルドと以前のビルドを読み込んで、それらの間で「コード カバレッジが 70% 未満の新しい型をすべて表示する」などのクエリを実行することもできます。これにより、既存のコードベースにより厳しいルールを導入できます。
これは素晴らしいツールであり、習得するのはそれほど難しくありません。情報量が多いので最初は怖いですが、強くお勧めします。
また、複雑なメソッド呼び出しの構造を理解する上でも非常に貴重だと思います。たとえば、特定のメソッドまたはフィールドを使用してすべてのメソッドを推移的に呼び出すことができ、循環呼び出し、不要な依存関係、または必要以上に複雑なパスなどに問題があるかどうかを確認できます。
依存関係グラフもインタラクティブになったので、現在興味のないメソッドを削除し、他のメソッドを移動して、何が起こっているかをよく視覚化できます。
実際、このツールは、別の人/ベンダーによって開発されたアプリケーションの別の部分で使用されているインターフェイスなどがある場合に役立ちます。インターフェイスを変更したいときはいつでも、誰があなたのインターフェイスを使用しているかを調べて、コードを壊さないようにする必要があります (アセンブリはビルドされません)。これは、より大きなプロジェクトに適用されます。
アセンブリのバージョン間の変更を視覚化すると便利であることがわかりました。特定のリリースでの変更のスナップショットでも...
CQL クエリを設定して、関心のあるコード メトリクス (循環的複雑度、長いメソッドなど) を測定できる継続的インテグレーション環境で優れていると思います。その後、それらの領域の改善を時間の経過とともに測定できます。
また、NDepend を使用して、アセンブリの 2 つのバージョンを比較しています。NDepend にはこの優れた機能があります。これにより、アセンブリの変更と作業の進行状況、追加されたメソッド、削除されたメソッドなどに関するビューが得られます。
このツールは、アプリケーションに膨大な数のアセンブリがある場合に役立ちます。コードの依存関係やリリース間の変更を見つけるのに役立ちます