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

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

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

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

P.S紧随其后的一篇文章
文章

解决方案

我绝对会建议我们阅读有关Joels的文章：

"捍卫未发明的综合征"

对于依赖项，我能想到的最好的度量标准是"如果这种情况消失，世界将陷入停顿"。例如，如果C ++的STL神奇地消失了，那么很多程序将停止工作。如果.Net或者Java消失，由于停止工作的产品数量，我们的经济可能会受到打击。

我会用这些话来思考。当然，如果消失了，许多事物在"世界末日"和" and"之间都是灰色的阴影。如果依赖消失，则依赖越可能导致世界末日，它就越有可能变得稳定，拥有活跃的用户群，其问题广为人知，等等。用户越多越好。

它类似于成为某些硬件组件的小使用者。有时硬件会过时。为什么？因为没有人使用它。如果我们是一家小公司，并且需要为产品获取组件，则可以选择常用的组件-"大玩家"的大量订购，希望这意味着(a)该组件不会消失，(b)组件的问题是众所周知的，(c)拥有大量知情的用户基础，并且(d)成本可能更低并且更容易获得。

但是有时候，我们需要特殊的磁通电容器零件，并且冒着这样的风险，即如果我们每年订购20个，并且似乎没人在乎，那么出售给公司可能就不会继续生产磁通电容器。在这种情况下，可能值得开发自己的磁通电容器，而不是依靠那种不可靠的Doc Brown Inc.。只是不要从利比亚人那里购买P。

如果我们从事某种制造工作(特别是当我们每年生产的数量远远少于数百万)时，就必须解决这个问题。我认为，必须以非常相似的术语来理解软件依赖关系。

如何将其量化为真实指标？大概算出有多少人依赖某物。如果此风险很高，则依赖关系伤害风险要低得多，我们可以决定在什么时候风险太大。

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

这使我们可以利用第三方库的功能，但是在调用该库时会大大降低复杂性(并因此减少了冗余)。该界面可确保我们不会让第三方库的特定样式渗入到项目中，并允许我们在认为有必要时轻松地将其替换为内部实现。

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

这样做的显着缺点是，它确实需要额外的开发并增加一定的维护影响(随着库中所需功能的增加而增加)，但允许我们利用第三方库而无需过多耦合，也不需要所有工作。开发人员需要了解它。

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

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

• 库的普及程度(如果需要，我可以找到支持者)
• 我有多大可能需要使用它做意外的事情(我最终要进行为期三周的任务以添加所需的功能吗？)
• 我需要使用其中的多少(我将花几天时间来学习功能，只是为了使用一项功能)
• 它看起来有多稳定(麻烦多于其值？)
• 接口的稳定性如何(下一两年可能会发生变化吗？)
• 这个问题有多有趣(我自己亲自实施该计划会更好吗？我会学到什么有用的东西吗？)