使用 NDepend 智能技术债务估算

距离我上次写一篇关于 NDepend 的博文还不到一年。我又在这里写一篇关于每个人都喜欢的很棒的静态分析工具的文章。我必须承认，在接触 NDepend 之前，我并不知道静态分析和分析器是什么。只有在了解了 NDepend 之后，我才确信这类工具真的能让我们的开发/管理生活变得简单、轻松、便捷。然而，在去年年中，我彻底转变为一个现在在 .net core 领域里吃、喝、睡的家伙。那时，任何静态分析工具都还没有支持 .net core 项目。但现在，在最新的版本 (2017.1.1) 中，NDepend 支持 .net core 项目了，相信我，在必须在庞大的代码库上对大量代码规则进行验证的编译过程中，它速度超级快。只需几秒钟。我也喜欢那个新酷炫的仪表盘，你可以在上面鸟瞰你的项目健康状况。

我在这篇 博文 中讨论了 NDepend 的一些核心功能。如果你想对 NDepend 有一个初步的了解，可以去看看。在这篇文章中，我将要讨论 NDepend 的一项新功能，称为智能技术债务估算。

技术债务（technical-debt）这个术语是由 Ward Cunningham 在 1992 年提出的一个比喻。简单来说，它表明对代码库中的问题应用一个可疑的解决方案，未来可能会给我们带来技术债务。如果一个快速而粗糙的解决方案导致我们以后需要花费额外的人力时间来支付利息，那么我们就应该通过考虑对解决方案进行重构来减少累积的利息。就像信用卡付款一样，如果你用信用卡购物，就被视为一笔贷款，利息会随着时间增长。你还清债务越快，你需要支付的利息就越少。这里也应用了同样的思想，你早期采取措施修复代码异味，将使你免受未来更大的债务。

Martin Fowler 进一步解释了这个比喻，使其更容易理解。在这篇 博文 中，他详细描述了技术债务的估算。

NDepend 可以通过其使用 C# LINQ 查询定义的专有规则集，更智能地估算技术债务。这些规则是高度可修改的，你应该根据你的需求修改它们。

让我们深入了解一些细节。我有一个项目，为 .net core 提供了一些自定义的请求/响应格式化程序。三天前，我安装了 NDepend 并对我的代码库进行了分析，但并没有真正理解 Baseline 这个术语的全部含义。今天，当我添加了一个新的格式化程序时，我故意将格式化程序类留空（未实现），然后再次运行了分析器。结果显示如下（之前和之后序列）。

三天前

今天（添加了一个新的未实现的格式化程序类后。）

如果你注意到顶部矩形框，有一个选项用于选择基线。正如你所看到的，NDepend 足够智能，能够将三天前生成的报告作为基线，当我重新分析时，它正在将该报告与我当前的报告进行比较；向我展示了添加到我代码库中的额外 债务。

右下角的矩形框中还有两个 主要问题。在它们失控之前，我应该修复它们。

还有一些 质量门，当我们尝试将更改推送到 源代码 或 生产环境 时，应该予以考虑。我们的代码必须通过质量门，无论如何。

现在，在我修复了这些主要问题并重新分析后，报告如下：

正如你所看到的，出现了三个新问题。这是因为我更改了代码库中某个类型的命名空间，以满足之前的规则集。我检查了这些规则集的 LINQ 查询，发现这行代码正在生成它们：

<code>(!m.WasRemoved() && m.ReturnType != null && m.NewerVersion().ReturnType != null
                     && m.ReturnType.FullName != m.NewerVersion().ReturnType.FullName)
</code>

现在，这些规则集正在做它们应该做的工作。当我修改一个类型（实际在我的其他方法中使用）的命名空间时，这确实会导致 API 破坏性更改。在这种情况下，你确切地知道你所做的更改实际上是为了改善你的代码库，所以你只剩下两个选择。要么修改并删除规则集中的这行代码（不推荐），要么将基线设置为 none 并再次运行分析。

我选择了第二个选项，并在再次运行分析后，我的报告现在看起来像这样：

请注意，一开始我的代码库的技术债务是 5.82%，现在减少了 13%。所以，API 破坏性更改实际上并没有那么破坏性，因为它只是与最后一个基线进行比较，并显示相对于该基线的警告。

现在，我应该说，NDepend 的这种智能技术债务估算技术确实非常智能。坦率地说；在体验了这项新功能和所有其他功能后；我确信并肯定我将使用 NDepend 以一种全新的方式来分析我的代码库。我不知道你怎么样，但对我来说，NDepend 是建立你代码库新司法体系的一种方式，就是这样！