冗余与依赖：哪个更糟？

Question

在开发新软件时，我通常会遇到冗余与依赖问题。也就是说，要么接受我有很大依赖关系的第 3 方库，要么自己编写代码会复制所有效果，但会减少依赖关系。

尽管我最近一直在尝试提出一种衡量代码冗余和代码依赖关系的度量方法。在大多数情况下，我已经得出结论，减少冗余会增加代码中的依赖性。减少代码中的依赖关系会增加冗余。所以它非常相互抵消。

所以我的问题是： 您过去使用过什么好的指标，并且确实用来衡量代码中的依赖关系或冗余？

我认为非常重要的一件事是，如果您选择依赖关系路线，您需要适当的工具集，以便您可以快速检查使用指定函数的所有例程和函数。如果没有这些工具集，似乎冗余会获胜。

P.S 继一篇文章
Article

Answer 1

我绝对会推荐阅读 Joels 的文章：

"In Defense of Not-Invented-Here Syndrome"

对于依赖项，我能想到的最佳指标是“如果这种情况消失，世界会陷入停顿吗”。例如，如果 C++ 的 STL 神奇地消失了，大量程序将停止工作。如果 .Net 或 Java 消失，我们的经济可能会因为停止工作的产品数量而受到打击……

我会这么想。当然，如果它们消失了，很多东西在“世界末日”和“meh”之间都是灰色的。如果依赖关系消失，它越接近可能导致世界末日，它就越有可能稳定、拥有活跃的用户群、众所周知的问题等等。用户越多越好。

它类似于成为某些硬件组件的小消费者。有时硬件会过时。为什么？因为没有人使用它。如果您是一家小公司并且需要为您的产品获取组件，您将选择通常可用的东西——“大玩家”大量订购的东西，希望这意味着（a）组件不会消失，（b）组件的问题是众所周知的，（c）有一个庞大的，知情的用户群，（d）它可能成本更低并且更容易获得。

但有时，您需要那个特殊的磁通电容器部件，并且您冒着风险，如果您每年只订购 20 个，那么卖给您的公司可能不会继续生产磁通电容器，而且似乎没有人关心:)。在这种情况下，可能值得开发自己的磁通电容器，而不是依赖不可靠的 Doc Brown Inc.。只是不要从利比亚人那里购买钚。

如果您从事过制造业务（尤其是当您的年产量远低于数百万件时），您就必须处理这个问题。我认为，软件依赖关系需要以非常相似的术语来理解。

如何将其量化为真正的指标？粗略计算有多少人依赖某事。如果它很高，依赖伤害你的风险就会低得多，你可以决定什么时候风险太大。

Answer 2

我之前并没有真正考虑过我用来决定是否使用第三方库的标准，但考虑过它，可能如下，没有特别的顺序：

• 图书馆的普及程度（如果我需要的话，我能否找到支持）
• 我需要用它做一些意想不到的事情的可能性有多大（我最终会开始为期三周的任务来添加我需要的功能吗？）
• 我需要使用多少（我要花几天时间学习来龙去脉只是为了使用一个功能）
• 它看起来有多稳定（麻烦大于价值？）
• 界面的稳定性如何（未来一两年可能会发生变化？）
• 这个问题有多有趣（我个人自己实现它会不会更好？我会学到什么有用的东西吗？）

Answer 3

如果外部软件为您的项目提供了很多价值，则可能的替代方法是使用它，但将其隐藏在简化（并且与您的项目更一致）界面之后。

这允许您利用第三方库的强大功能，但在调用该库时的复杂性（以及冗余度）大大降低。该接口可确保您不会让第三方库的特定样式渗入您的项目，并允许您在认为可能有必要时轻松地将其替换为内部实现。

这种情况发生的迹象可能是您要支持的接口受到第三方库的阻碍。

这样做的显着缺点是它确实需要额外的开发并增加一定的维护影响（这会随着您需要从库中获得的功能数量而增加），但允许您利用第三方库而无需过多的耦合和您的所有开发人员都不需要了解它。

一个很好的例子是在一组存储库或数据访问对象或使用依赖注入框架实现的工厂之后使用对象关系映射器 (Hibernate\NHibernate)。