从昨天开始，我正在使用Ndepend分析我们的一个项目（其大部分功能免费），而且我正在使用它，而且我更怀疑这种软件（代码分析软件）的真正价值。
让我解释一下，系统通过对每个指标进行排名来构建关于系统和类的健康状况的报告。我认为这是进行修改的一个很好的起点，但大多数最佳结果都在这里，因为它们在类中有超过 100 行（我们有大标题，我们确实使用 VS 注释样式）所以这没什么大不了的。 .比传入耦合级别（CA）的数量总是太高，这对于我们经常使用的接口来说几乎是非常正确的......所以此时我没有看到有什么问题，但 NDepend 似乎不喜欢它（如果您有改进建议，请告诉我，因为我认为没有必要）。对于我的大多数界面都太高的孩子数量的称为“NOC”的指标来说，这是一样的......
目前，唯一非常有用的指标是圈复杂度......
我的问题是：你觉得用 NDepend 之类的自动代码分析器分析代码值得吗？如果是，您如何过滤我提到的所有信息，这些信息并不能真正显示系统的真实健康状况？
我不一定将 NDepend 的结果视为软件工程中的“好”或“坏”，应用程序的设计方式总是有充分的理由。我认为它是一份报告，可能可以帮助我指出我的设计问题，但在决定一个方法是否需要重构或者它是否符合我的设计方式时，我有最终决定权。一般来说，不要太着迷于试图回答是否值得。绝对是，相反，我建议您仔细查看结果。这将帮助您从另一个角度查看您的设计，并且在某些情况下，您可能会决定设计它的方式是实现应用程序目标的最佳方式。
实际上指标只是 NDepend 的一项功能，您是否尝试使用 VisualNDepend 让您比报告更深入地分析您的项目？通过阅读您的评论，我几乎可以肯定您没有使用 NDepend UI（独立或集成在 Visual Studio 中），这是过滤代码库数据的最佳方式。
我是 NDepend 的开发人员之一，我们经常使用它来分析我们自己的代码。基本上，我们使用基于LINQ 查询的代码规则 (CQLinq)编写自己的质量规则。这些规则自动确保我们的设计没有回归。在这里，您将找到大约200 条默认代码规则的列表。
以下是 NDepend 的一些独特功能，与代码指标无关：
编写 CQLinq 规则以确保我们没有架构缺陷，例如组件之间的依赖循环、直接使用 DB 的 UI或与业务对象纠缠的 DB。
确保我们在测试的代码覆盖率方面没有问题（就像我们使用 CQLinq 规则确保如果一个类应该被 100% 覆盖，那么它将在未来保持 100% 覆盖）
强制执行无副作用的代码（不可变类/纯方法）
在发布新版本之前，使用将 2 次分析与自上次发布以来的代码审查更改进行比较的能力。更具体地说，我喜欢使用 NDepend 来了解自上次发布以来添加和重构了哪个方法，并且测试没有 100% 覆盖。
对我们所有的成员和类型进行最佳封装（比如知道哪些内部方法可以声明为 private）。这也与NDepend 也支持的死代码检测有关。
有关 NDepend 的完整功能列表，请参见此处。