ディペンデンシー グラフを作成するときに何を探す必要がありますか?
別の言い方をすれば、見栄えの良いグラフと悪いグラフの特徴は何ですか?
編集: ここでのコンテキストは、NDepend で私のアセンブリを初めて見たものです。
ディペンデンシー グラフを作成するときに何を探す必要がありますか?
別の言い方をすれば、見栄えの良いグラフと悪いグラフの特徴は何ですか?
編集: ここでのコンテキストは、NDepend で私のアセンブリを初めて見たものです。
あなたが見つけることができる最大の問題は、間違いなく依存関係の循環です。ツール NDepend は、依存関係のサイクルを見つけるのに役立つインタラクティブな依存関係マトリックスと依存関係グラフを提案します。免責事項: 私はツールの開発者の 1 人です。
依存関係マトリックスは、グラフからスポットへのサイクルよりもはるかに適応していることに注意してください。サイクルは行列が三角形になるのを避けるためです。
他の範囲の問題は、アプリケーションの構造に関連しています。たとえば、UI が DB を直接使用するのは正常ですか? さらに悪いことに、DB は UI に依存していますか?
LINQ クエリ (CQLinq) に対してコード ルールを記述して、禁止されている依存関係をチェックできます。次のコード ルールは、UI タイプが DB タイプを直接使用してはならないことを確認します。
// <Name>UI layer shouldn't use directly DB types</Name>
warnif count > 0
// UI layer is made of types in namespaces using a UI framework
let uiTypes = Application.Namespaces.UsingAny(Assemblies.WithNameIn("PresentationFramework", "System.Windows", "System.Windows.Forms", "System.Web")).ChildTypes()
// You can easily customize this line to define what are DB types.
let dbTypes = ThirdParty.Assemblies.WithNameIn("System.Data", "EntityFramework", "NHibernate").ChildTypes()
// Ideally even DataSet and associated, usage should be forbidden from UI layer:
// http://stackoverflow.com/questions/1708690/is-list-better-than-dataset-for-ui-layer-in-asp-net
.Except(ThirdParty.Types.WithNameIn("DataSet", "DataTable", "DataRow"))
from uiType in uiTypes.UsingAny(dbTypes)
let dbTypesUsed = dbTypes.Intersect(uiType.TypesUsed)
select new { uiType, dbTypesUsed }
何の依存関係グラフ? クラス?ストアドプロシージャ?
周期が悪い…
NDependが何を示しているかはわかりませんが、コードの多くのセクション(特に無関係なセクション)に入る傾向のあるアーティファクトは悪い傾向があります(IMHO)。それを「がんコード」と思っていました。
1 つの依存関係を変更することで、他の多くの依存関係を変更する必要がある場合、それは悪いことです。
しかし、そうです、いくつかのコンテキストが役立つ可能性があります。
NFJS カンファレンスの講演者は、いくつかの依存関係グラフを見せてくれました...彼が指摘した 1 つの匂いは、コードベースのさまざまな機能部分との関係を探すことでした。これらはカプセル化を破る可能性があります。
また、各セクションの一般的な複雑さを調べます.全体に線があるものは疑わしいです.