2010-01-12 47 views
23

我一直在尝试NDepend,一直在阅读一些关于它的博客文章,甚至听过播客。我认为NDepend可能是一个非常有用的工具,但我仍然不知道我会在哪里使用它。你使用NDepend吗?

你如何使用它?你用它,为什么?为什么不?

我想听听一些脚踏实地的真实世界的例子。

+1

您可能需要添加一些标签(例如平台/语言/技术NDepend的是)的问题对人们的“最爱”的标签出现。 – 2010-01-12 15:06:13

回答

28

我在过去几年中广泛使用了NDepend。基本上它是一个依赖分析工具,所以这可以帮助你解决很多与依赖相关的问题。

我使用它的一个主要事情是检查我的程序集,类型和方法之间的依赖关系。这有助于我了解类型之间的耦合是否失控,并帮助我发现重构机会。

当开始大规模的重构时,提取.movi​​ng类型到其他程序集,这可以让你看到什么取决于什么,所以你不必做旧的“将我的类型移动到另一个程序集,然后尝试编译并查看什么是中断点”。NDepend也有一个用于查看这类信息的良好视觉矩阵。

此外,它还有一个奇妙的查询语言CQL,它允许您编写自定义查询。这些可以是简单的事情,例如“显示所有调用此方法的方法”,查询以突出显示死代码,查询环状复杂性,耦合等等,以及更多。

反过来,它可以集成到构建过程中,因此您可以基于CQL查询构建警告/失败,例如“如果一个方法有超过100行代码但没有注释,则构建失败”(这是一个例子 - 我不建议这个特定的度量标准是一件好事)。

它还可以导入代码覆盖率数据,并为您提供几乎没有代码覆盖的区域的可视化表示,以及允许您针对代码覆盖率信息运行CQL查询(例如,向我展示代码覆盖率小于70%的方法)

您也可以加载当前构建你的项目,和以前的版本,并运行它们之间的查询,如“显示我的所有类型有< 70%的代码覆盖率” - 这可以帮助您介绍更严格的规则在现有的代码库上。

这是一个神奇的工具,并不太难学。一开始就很可怕,只是因为它提供的信息量很大,但强烈建议。

+2

+1您点击使用该工具的所有要点。我将补充一点,依赖关系图对于代码结构的高级视图非常有用。 – 2010-01-18 21:42:54

4

我发现可视化组件版本之间的变化很有用。即使对于给定版本中的更改快照...

我认为它可以在持续集成环境中发光,您可以设置CQL查询来测量您感兴趣的代码度量(Cyclomatic Complexity,Long Methods等。),然后你可以衡量你在这些领域的进步。

4

其实这个工具是有帮助的,如果你有,例如,由另一个由不同的人/供应商开发的应用程序的另一部分使用的接口。每次你想改变界面,你都必须找出谁在使用你的界面,以避免破坏它的代码(汇编不会被编译) 这适用于更大的项目。

8

我也觉得理解复杂的方法调用的结构非常宝贵的。例如,我可以使用特定方法或字段传递调用所有方法,并且可以查看是否存在循环调用可能存在的问题或不需要的依赖关系,或者路径是否比所需的更复杂等。

依赖关系图现在也是交互式的,所以我可以删除我目前不感兴趣的方法,并且移动其他方法以便对发生的事情进行良好的可视化。

2

这个工具是有用的,当你的应用程序组件的数量巨大。 它帮助我找到了释放

2

之间的代码依赖关系和以及我还使用NDepend的比较一些组件的两个版本的变化。 NDepend具有这个卓越的功能。这让我可以查看汇编中的更改和工作进度,添加的方法,删除的方法等等。