组合重用_重用困境

组合重用

年轻程序员学习的第一条诫命是“你不可重复”。 如此指示，每当我们看到看起来像是重复代码的东西时，我们就会进行重构。 我们创建库和框架。 但是删除重复项并不是免费的。

如果我重构一些代码，以使它们不必在类A和类B中复制某些逻辑，而可以在类R中共享逻辑（以便重用！）。 现在，A类和B类是间接耦合的。 这不一定是一件坏事，但会带来一些后果，而这些后果往往被忽略。

如果A类需要更改共享功能，则可以选择：我们进行更改或阻碍A类。进行更改的代价是破坏B类。如果这些类在同一Java包（或.NET）中，命名空间），那么我们就有可能验证更改没有破坏任何内容。 如果重用功能在由B类使用的另一个库使用的库中，则很难确认更改是否正确。

这是进行持续集成的地方。我们检入对类R的更改（请记住，以备重用）。 Jenkins，Bamboo，TFS或您所拥有的将触发构建。 该构建导致其他项目的构建，最终，我们得到了失败的构建，其中B类的单元测试中断了。 如果我们做对了。

即使测试失败，我们也不例外。 大型企业的构建系统可能需要一个小时甚至更长的时间才能运行。 这意味着，通过尝试改进R类，A类的开发人员至少在一段时间内已经使B类的开发人员陷入困境。

当组织由于依赖关系的更改而看到重复的构建中断时，React通常是相同的：让限制更改共享代码。 也许我们甚至会对其进行版本控制，以便您所需的任何更改都将在下一个版本中发布，并且依赖项可以按照自己的进度进行升级。

现在，我们引入了另一个问题：我们不再能够更改代码。 A类的开发人员必须照原样采用R类，或者至少要进行大量工作才能对其进行更改。 如果重用的代码非常成熟，那就很好。 毕竟，对于语言标准库和开源项目，这是我们必须处理的问题。

但是，组织内大多数重用的代码还不那么成熟。 A类的开发人员通常会因R类的限制而感到沮丧。如果重用的类是特定于领域的，则限制会更糟。

因此，开发人员会执行任何合理的开发人员会做的事情：他们制作R类的副本（或者在R所在的存储库中派生），从而创建新的代码重复。

事实如此：删除重复会导致重用器之间发生不利交互的风险。 组织对重用代码执行更改控制，以避免在一个上下文中进行的更改破坏系统的其他部分，从而导致需要重用代码进行更改的重用程序瘫痪。 重用程序最终将重用的代码复制到他们自己的分支，在那里他们可以对其进行演化，从而导致重复。 直到有人希望删除重复项。

困境发生在小公司和大公司之间，但是权衡是不同的。

我们应该少做的是重用价值不高的未成熟代码。 额外耦合的成本通常远远超过重用的好处。

翻译自: https://www.javacodegeeks.com/2014/10/the-reuse-dilemma.html

组合重用