在特殊情况下，我们可以接受重复的代码吗？

我正在一个软件项目中，我们必须构建三个API。一个用于家庭银行业务渠道，一个用于代理渠道，第三个用于移动渠道。

代理API是最完整的API，因为它具有所有功能。然后是更小的Home API，然后是移动API。

此处的架构师建立了一个公共层（所有API共享的跨通道EJB服务）。但是那时的API是不同的。

目前，这些API之间没有太大的区别。大型团队从代理商渠道开始，现在我们正在对其进行调整以适合家庭渠道。我们只是在为我们的家庭应用专门添加对象。否则，API之间的代码相似度为95％。这些API建立在Spring MVC之上，并且具有（控制器，模型和一些实用程序）。

基本上，控制器正在将BO映射到ChannelObject（在我看来，这样做不合适的地方），以及一些额外的实用程序和序列化程序。目前所有重复项。他们说重复的原因是他们希望API独立。“如果明天我们想要的家庭行为不同于代理商或移动设备，我们将不会挣扎！”

是否存在我们应该接受重复代码的情况？

复制可能是正确的选择，但并非出于这个原因。

说“即使现在它们是相同的，我们可能希望代码库中的这三个位置表现不同”，这并不是大规模复制的好理由。这个概念可能适用于每个系统，并且可以用来证明任何重复是合理的，这显然是不合理的。

仅当删除时才应允许重复，否则由于其他一些原因，复制现在总体上会变得更加昂贵（暂时无法想到一个好的复制品，但可以肯定的是，复制是可行的-编程中的几乎所有内容都是折衷而不是法）。

对于您正在做的事情，正确的解决方案可能是例如将立即复制的行为提取到策略或某种将行为建模为类的其他模式中，然后使用同一类的三个实例。这样，当您确实要在三个位置之一中更改行为时，只需创建一个新的Strategy并将其实例化在一个位置。这样，您只需要添加一些类，而剩下的代码库几乎完全不受影响。

桑迪·梅茨（Sandi Metz）是Ruby生态系统中的著名软件工程师和作家，她在一篇出色的博客文章中发表了演讲，并在演讲中还谈到了复制和抽象之间的关系。她得出以下结论

复制比错误的抽象要便宜得多

我完全同意她的看法。让我为您提供更多有关此报价的背景信息。有时很难找到正确的抽象。在这种情况下，很容易尝试进行任何抽象以减少重复。但是稍后您可能会发现您的抽象并不适用于所有情况。但是，再次更改所有内容并走另一条路线的成本很高（有关更好的解释，请观看她的演讲！）。

所以是的，对我来说，在某些特殊情况下，接受重复是正确的决定，尤其是当您不确定将来会发生什么并且需求可能会发生变化时。从您的帖子中，我认为现在有很多重复项，但是您的同事建议这可能会改变，并且不要将两个应用程序相互耦合。在我看来，这是一个有效的论点，通常不能忽略。

如果人们开始使用“如果明天”一词来进行设计推理，这对我来说通常是一个很大的警告信号，尤其是当该论点用于证明一项包括额外工作和努力的决定的合理性时，没人真正知道这是否会实现还清，这比相反的决定更难更改或还原。

代码重复仅在短期内减少了工作量，但是它将几乎立即增加维护工作量，与代码重复行的数量成正比。还要注意，一旦代码被复制，当发现这是一个错误的决定时，将很难删除复制，而如果现在不复制代码，则如果后来发现坚持使用DRY，仍然很容易引入复制。是错误的决定。

据说，在较大的组织中，有时有利于支持不同团队独立于DRY原则。如果通过提取两个API的95％共同部分来消除重复，则新组件导致两个原本独立的团队的结合，这可能不是最明智的决定。另一方面，如果您的资源有限，并且只有一个团队维护这两个API，那么我相信不做任何双重努力并避免任何不必要的代码重复对他们自己有利。

还要注意，如果“ Home”和“ Agency” API仅由完全不同的应用程序使用，或者如果人们可能试图在也可以在“ Home”上下文中使用的那些API之上编写组件构建，则这将有所不同。就像在“代理商”上下文中一样。在这种情况下，使API的公共部分完全相同（只有在公共部分不重复的情况下才能保证），这可能会使此类组件的开发更加容易。

因此，如果事实证明确实存在不同的子团队，每个子团队负责每个API，每个子团队具有不同的时间表和资源，那么该是时候复制代码了，但不是“以防万一”。

复制以防止耦合。假设您有两个大型系统，并强迫它们使用相同的库。您可能正在耦合两个系统的发布周期。这可能还不错，但是假设一个系统需要进行更改。其他需要分析更改，并且可能会受到影响。有时它可能会破坏事情。即使双方都能协调变更，也可能要召开许多会议，包括经理，测试，依存关系以及小型自治团队的结束。

因此，您要付出重复代码的代价，以获得自治和独立性。