冗余与依赖：哪个更糟？

Question

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

虽然我最近一直试图想出一种衡量代码冗余和代码依赖性的度量方法。在大多数情况下，我总结说减少冗余会增加代码中的依赖性。减少代码中的依赖关系可以增加冗余。所以它非常反对。

所以我的问题是： 你曾经使用过一个很好的指标，并且用来衡量代码中的依赖关系或冗余吗？

我认为最重要的一件事是，如果您选择依赖路径，则需要使用工具集，以便快速检查使用指定函数的所有例程和函数。如果没有设置这些工具，似乎冗余会胜出。

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公司。只是不要从利比亚人那里购买钚。

如果你已经开始制造某些产品（特别是当你每年制造的产品远远少于数百万件时），你就必须处理这个问题。我认为，软件依赖性需要以非常相似的术语来理解。

如何将其量化为真实的指标？粗略计算有多少人依赖某些东西。如果它很高，依赖性伤害你的风险要低得多，你可以决定风险是多少。

Answer 2

我之前没有真正考虑过我用来决定是否聘用第三方图书馆的标准，而是考虑过它，可能是以下内容，没有特别的顺序：

• 图书馆有多广泛（如果我需要的话，我能找到支持）
• 我有多大可能需要用它做出意想不到的事情（我最终会开始执行为期三周的任务以添加我需要的功能吗？）
• 我需要使用多少（我将花几天时间学习这些细节以利用一个功能）
• 看起来多么稳定（比它的价值更麻烦？）
• 界面的稳定性（未来一两年内可能会发生什么变化？）
• 这个问题多么有趣（我个人最好自己实施它？我会学到什么有用的东西吗？）

Answer 3

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

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

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

这方面的重大缺点是它确实需要额外的开发并增加一定的维护影响（这会随着您从库中获得的功能量而增加），但是允许您利用第三方库而不需要太多的耦合和没有你所有的开发人员需要理解它。

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