NDepend 6の新機能の概要

NDependはHabréで既に述べられています-これは.NETの静的コードアナライザーです。 最近、新しい素晴らしいユーティリティの第6バージョンがリリースされました。その新しい機能については以下で説明します。 これは翻訳です 。元の記事はこちらです。

新機能の正しい選択

最近リリースされたNDepend 6 。 これまで、メジャーリリースのリリースはVisual Studioのリリース後しばらくの間予定されていましたが、現在Visual Studio 2015はプレリリース状態です。 NDepend 6は、18か月間のハードワークの結果です。 11年の開発の後、 NDependは一定の成熟度に達しましたが、まだ多くの機会と改善が可能です。 また、バージョン6の最もデリケートな問題は、ユーザーのために新機能と改善を選択することでした。 バージョン5が2013年にリリースされて以来、 Visual Studio User VoicesおよびNDepend User Voicesでアイデアが寄せられています 。 実際のところ、第6バージョンの新機能は、完成された最も人気のある機能をよく反映しています。

ビルドプロセスへの統合

ユーザーは、NDependを自動ビルドプロセスにさらに統合することを要求しています。 NDepend.Console.exeを実行して、情報を収集し、ビルドプロセスを失敗させる重要なルールに違反しているかどうかを報告しました（この情報は、NDepend.Console.exeからのリターンコードから取得できます）。 ユーザーは、ビルドツールでより多くの情報を直接表示するように求められました。 多くのビルドテクノロジがありますが、最も要求されるのはTFS 、 TeamCity 、およびSonarQubeです。 その結果、開発者はこれらのテクノロジーの最高の専門家と協力して、組み込みの統合を行いました。これには、ほとんどの使用シナリオが含まれており、将来のバージョンでサポートされ、新しい機能が追加されます。

Visual Studio統合の改善

なぜなら ユーザーはビルドプロセスとの統合をさらに望んでいたため、過去1年間、主にVisual Studioのツールに力を注いできました。 NDependは、VS Addinテクノロジーを使用してVisual Studioに統合されました。この決定は、2009年に開発チームによって行われました。 当時、VSIX（スタジオ用の拡張機能を開発するための別の手段）は未加工であり、VS2008とVS2005をサポートする必要もあったため、VS Addinが正しい選択でした。 時間が経つにつれて、VSアドインの重要性は低下し、Microsoftからの改善も受けず、クラッシュに至りましたが、最も重要なことは、実行時にNDependウィンドウの場所を覚えることができなかったことです。 これはユーザーに大きな不便をもたらし、 ユーザーボイスがウィンドウの場所を記憶するよう要求する結果となりました。

バージョン6以降、NDependはVS 2015、2013、2012、2010への統合のためのVSIXテクノロジーに基づいています。さらに、Microsoftは2015スタジオでのVS Addinの使用を禁止しています。 いずれにせよ、VSIXのおかげで、ウィンドウの記憶、新機能（たとえば、NDependプロジェクトを.suo（.slnだけでなく）にアタッチし、ホットキーを完全にサポート）により、Visual Studioとのスムーズで信頼性の高い統合を実現することが可能になりました。

また、NDependに含まれていた無料のスタジオ拡張機能によって提供される3つの機能があり、常に手元にありました。

ルールの機能強化

.NETコードのルールは、NDependの主な機能です。 ユーザーは、主に誤検知を減らすために、既存のルールを改善する方法について多くのフィードバックを残しました。 そのため、デフォルトルールの約3分の1が推奨に従って再作成されました。

コードのルールが、いくつかのコメントを含むC＃ mutable LINQクエリであることは素晴らしいことです。 しかし、多くのユーザーにとって、ルールが警告を生成した理由、特定のルールへの準拠がコードを改善する理由、ルール違反を修正する方法について十分な情報がありませんでした。 そのため、 <Description>および<HowToFix>タグを使用して、NDependルールのソースコードに2つのフォーマットされたテキストを追加する機能が追加されました。 これは、デフォルトで各ルールを説明し、ユーザーに詳細に説明する良い機会です。 インターフェイスとレポートの両方で、ユーザーは監視するものを選択できます-Description / HowToFixまたはC＃LINQのルールのソースコード。



ユーザーのもう1つのニーズは、複数のNDependプロジェクト間でルールを使用可能にすることでした。 通常、企業にはNDependを使用して分析された複数のプロジェクトがあり、ユーザーはそれらを一度にすべて管理したいと考えています。 そして、.NETコードのNDependルールを書くことは他のどこよりも簡単であることを考慮して、ユーザーは異なるプロジェクトに1つのプロファイルを使用する機能を望んでいました。 したがって、NDepend 6では、NDependプロジェクトで一緒に使用できるルールのリストを定義できます。

コードメトリックの視覚化

NDependにはtreemapを使用したコードメトリックの視覚化がすでにあり、色付けを追加することが決定されました。 アイデアは、2つのコードメトリックを表示できるということです。 1つは長方形の領域で表され、もう1つは長方形の色で表されます。 たとえば、次の図は、特定の、しかし便利で正確な方法でのテストによるNDepend 6コードのカバレッジを示しています。

• 長方形-メソッド、
• 長方形の領域はコードの行数に比例し、
• 長方形の色は、テストでのコードカバレッジの割合です。

一見すると、カラーツリーマップは、他の方法では理解するのが難しい情報を理解するのに役立つことがすぐにわかります。 NDependコードはテストで82％カバーされているという事実にもかかわらず、テストで十分にカバーされていないコードを示す赤い長方形のクラスターを見ることができます。 このような精度でこれを表示できるツールはおそらくもうないでしょう。

NDepend開発者は、製品の機能を統一しようとしています。 したがって、 NDependの多くのメトリックのうち2つだけでなく、C＃のLINQクエリで記述されたコードメトリックも視覚化でき、ルールまたはクエリの最終コードを強調表示することもできます。 その結果、複雑なメソッドをリクエストした場合、それらをカラーツリーマップに表示できます。



それは注目に値する テストでのコードカバレッジは最も重要な品質インジケータの1つであり、クエリコードの結果には、このための別のインターフェイスも追加されています。

他にやるべきこと

製品は絶えず変化する環境にあります。 これは、以前に機能していたいくつかの機能を確認する必要があることを意味します。 これらの必要な改善の一部は、NDependバージョン6で行われました。

C＃およびVB.NETコンパイラーによって生成されたヘルパーコード：バージョンごとに、C＃およびVB.NETにはますます多くの砂糖が登場しました。 C＃2.0の匿名メソッドとイテレータで始まりました。 次に、ラムダと匿名型がC＃3.0に登場し、C＃5.0でasync / awaitが登場しました。 これらの構成体は、コンパイラに追加のメソッドと型を生成させる。 そしてなぜなら これらの構成要素は非常に頻繁に使用され、生成されたこれらの要素はILコードに蓄積されます。 また、 NDependはILコードに大きく依存してコード情報を取得します 。 したがって、NDependコードモデルには、生成されたすべてのメソッドと型が含まれ、これは主に自分のコードだけに関心があるユーザーを悩ませます。 現在、NDependはこれを修正しています。 これらの生成された要素をすべて取り除くことは、オプションではありません。 実際には、いくつかのユーザーコードが含まれています。 そのため、これらの生成された要素を、コンパイラに生成させるコードを含むカスタムクラスおよびメソッドと組み合わせるために、いくつかのヒューリスティックが開発されています。 したがって、妥協する必要はありませんでした。コードメトリック（行数、カバレッジの割合、循環的複雑度など）、依存関係、違いなど、すべてのコードモデルデータが保存されました。

非同期サポートの改善：非同期コンストラクトは固有であり、NDependでいくつかの問題を引き起こしました。 カスタムコードは、生成されたメソッドにコンパイラーによって実際に埋め込まれ、 IAsyncStateMachine.MoveNext（）仮想メソッドをオーバーライドします。 したがって、この生成されたMoveNext（）メソッドを呼び出すILコードは、実装ではなく抽象インターフェースメソッドに関連付けられます。 非同期メソッド呼び出しはILコードで失われるため、NDependコードモデルで失われます。 前の段落のために書かれた発見的手法のおかげで、NDependは正しい呼び出し非同期メソッドを分析および識別することができるようになりました。

高解像度のサポート：高解像度モニター（4Kなど）が利用可能になり、その結果、より多くの開発者が適切なWindows設定で作業しています。 これは、ピクセル密度が高いため、グラフィック要素（テキスト、画像）を表示するためにより多くのピクセルが使用されることを意味します。 NDependのインターフェイスは主にWindowsフォームとGDI +に基づいており、Windowsが高解像度に設定されている場合、これらのテクノロジーはデフォルトではあまりうまくスケーリングしません。 ユーザーがこの問題を報告し始めたとき、NDependインターフェース全体をやり直して、100％から250％の解像度設定で動作するようにしました。 これは、いくつかのグラフィック要素を改善し、Windows FormとGDI +を高解像度で使用するいくつかの方法を学ぶ機会でした。 この結果は、今後のNDependブログ投稿で説明されます。 インターネット上では、これが多くの開発者にとって問題であることは明らかです。

Visual Studioのトピック：統計によると、ほとんどのユーザーはVisual StudioのNDependを使用しています。 したがって、NDependインターフェイスのテーマは、Light、Dark、Blueなどの標準のVisual Studioテーマや標準のVS2010テーマとうまく調和しません。 幸いなことに、NDependでは、メニュー項目、パネル、バインディングなどはDevExpress WinFormライブラリに基づいており、最新バージョンにはこれらのテーマが含まれています（これらだけではありません）。 したがって、最新バージョンへの簡単な更新が役立ちました。

分析の改善：分析に関連していくつかの改善が行われたはずです。 NDependのプロジェクトは、いくつかのディレクトリとアセンブリ名（ファイル拡張子なし）を参照します。 分析中、分析するアセンブリの場所は次の2つの方法で見つかりました。 アセンブリのコピーが多数見つかった場合、それらがすべて同じである場合、NDependはそのうちの1つを取得し、異なる場合、NDependはエラーを報告しました。 この状況は、ソリューションの展開の重大な問題と見なされます。 しかし、時間が経つにつれて、Windows Phoneやポータブルクラスライブラリなどの新しいテクノロジが登場し、適切な操作中にこのような状況が発生しました。 したがって、このような状況が検出されると、NDepend 6はヒューリスティック分析を使用して、バージョン、依存関係、およびファイルサイズに基づいて正しいアセンブリを見つけます。