复制和粘贴编程真的有问题吗？

复制和粘贴编程 –复制项目中现有代码的副本并重新使用它–违反了“ 不要重复自己（DRY）”之类的编码最佳实践。 它是最常引用的技术债务示例之一，这是一种懒惰的工作方式， 草率且目光短浅 ：一种反模式，这增加了保持代码库存活的长期成本。

但这也是完成工作的自然方法-找到已经可以使用的东西，看起来与您想要的东西相近的东西，进行复制并以它为起点。 几乎每个人都在某个时候做了。 这是因为有时候复制和粘贴编程不仅方便，而且可能也是正确的做法。

首先，让我们弄清楚复制和粘贴的意思。 这并不是从Internet上复制代码示例 ，这种做法有其自身的优点和问题。 通过复制和粘贴，我的意思是程序员在重用捷径时–当他们需要解决与系统中另一个问题类似的问题时，他们将从复制现有代码并更改所需内容开始。

在设计和开发的早期，复制和粘贴编程没有真正的优势。 代码和设计仍然是可塑的，这是您提供合适的抽象，例程和库来完成系统所需功能的机会。 无论如何，没有太多可以复制的内容。 当您已经准备好许多代码时，尤其是在维护大型的，长期存在的系统时，复制和粘贴参数变得更加复杂，这是开发的后期。

为什么要复制和粘贴？

程序员可以复制和粘贴，因为这样可以节省时间。 首先，您有一个起点，即您知道有效的代码。 您要做的就是找出需要更改或添加的内容。 您可以专注于您要解决的问题，不同之处，而您只需要了解您将实际使用的内容。 您可以更自由地进行迭代并进行更改以适应您面前的问题-您可以在需要时清除代码，删除不需要的代码。 所有这些都很重要，因为在您更深入地解决问题之前，您可能不知道需要保留什么，需要更改什么以及根本不需要什么。

复制和粘贴编程还可以降低风险。 如果您必须返回并更改和扩展现有代码以执行其今天的工作以及解决新问题，则冒着破坏已经起作用的事情的风险。 通常，从那里复印并工作更安全，更便宜（至少在短期内如此）。

如果您要构建新的B2B客户界面，以供新的一组客户使用，该怎么办？ 以现有接口为起点，至少重复使用脚手架，管道和接线以及尽可能多的业务代码，然后查看需要进行哪些更改，这可能是有意义的。 最后，两个接口都将使用通用代码（毕竟，这就是您要复制的原因），但是可能需要一段时间才能知道该代码是什么。

寻找通用设计，正确的抽象和变体以支持不同的实现并处理异常可能是困难且耗时的。 您可能最终会遇到难以理解，难以维护和更改的代码，因为原始设计无法预期到不同的异常和扩展，而重构只能使您走得那么远。 您可能需要新的设计和实现。

更改现有代码，将其重构或重写为通用，共享和可扩展的代码将增加成本，并增加摆在您面前的工作的风险。 您不能仅仅因为您想要使一些新客户上线而为现有客户和合作伙伴制造问题。 您需要格外小心，不仅要了解您现在尝试做的事情（新界面）的细节，还需要了解现有界面的所有细节，其行为和假设，因此您可以保留所有内容。

幼稚地认为所有这些行为都将在您的自动化测试中捕获–假设您有一套很好的自动化测试。 您需要返回并在现有界面上重做集成测试。 要使可能已经花费数周或数月时间来测试该软件以重新测试它的客户和合作伙伴既困难又昂贵。 他们（理所当然地）认为不需要花费时间和金钱，因为他们所拥有的已经可以正常工作了。

现在复制和粘贴，并计划以后再重构或重构（如有必要）以实现通用解决方案是正确的方法。

当复制和粘贴有意义时

在“ 制作软件 ”的“将粘贴作为一种有原则的工程工具”一章中，Michael Godfrey和Cory Kapser探索了复制和粘贴编程的成本，以及复制和粘贴有意义的情况：

1. 分叉–出于硬件或平台变体或出于探索性原因而故意创建变体。
2. 模板–有些语言不支持库和共享功能，因此可能需要复制和粘贴以共享代码。 早在某个时候，第一个COBOL程序员就编写了一个完整的COBOL程序-之后的每个人都互相复制和粘贴。
3. 定制-创建临时的解决方法-只要它是临时的。
4. 微软“克隆并拥有”解决大型开发组织中的问题的实践。 一个团队从另一组中获取代码并对其进行自定义或对其进行调整以适应自己的目的-现在他们拥有自己的副本。 这是使用开放源代码的通用方法，它被用作基础，并且需要扩展以解决专有问题。

当复制和粘贴成为问题时

何时复制和粘贴，以及随着时间的推移会出现多少问题，取决于一些重要因素。

首先，您要复制的内容的质量–代码的可理解性，稳定性如何以及其中有多少错误。 您不想从继承别人的问题开始。

已制作了多少份。 Fowler和Beck的《 重构》一书中的一个普遍经验法则是“三击就重构”。 该规则来自于认识到，通过复制已经在使用的内容并更改副本，您已经创建了一个小的维护问题。 可能尚不清楚此维护问题是什么还是如何最好地解决，因为只有两种情况并不总是足以了解什么是常见的和什么是特殊的。

但是，您制作的副本越多，就会造成更多的维护问题–更改和修复多个副本的成本以及错过更改或修复所有副本的风险。 到制作第三份副本时，您应该能够看到模式-代码之间有什么共同点，什么不是共同点。 而且，如果您必须以三种相似但又不同的方式来做某事，则很有可能会有第四个实现，第五个实现。 到第三次时，值得回过头来重组代码并提出一个更通用的解决方案。

您必须多久更改一次复制的代码并使之保持同步-尤其是，您必须在多个位置更改或修复同一代码的频率。

您对代码的了解程度如何，是否知道存在克隆以及在何处找到它们？ 查找副本需要多长时间，以及您是否确定全部找到了副本。 工具可以帮助您。 诸如克隆检测器之类的源代码分析工具可以帮助您查找复制和粘贴代码-完全不同的副本和相似但不相同的代码（模糊的匹配与模糊的结果）。 随着时间的流逝，不同的程序员常常会费劲地复制代码，这使得工具更难找到所有副本。 一些程序员建议您在制作副本时在代码中留下注释作为标记，突出显示副本的来源，以便将来进行修复的维护程序员可以查找并检查其他代码。

复制和粘贴编程不是免费提供的。 但是，与软件开发中的许多其他想法和实践一样，复制和粘贴编程不是对还是错。 它是可以正确使用或滥用的工具。

布莱恩·富特（Brian Foote）是最早认识软件设计中泥泞大球问题的人之一，他说复制和粘贴编程是程序员实际上遵循的一种重用形式 ，因为它可以工作。

认识到这一点很重要。 如果要复制和粘贴，让我们对其负责。

参考： 复制和粘贴编程真的有问题吗？ 来自我们的JCG合作伙伴   Building Real Software博客上的Jim Bird。

翻译自: https://www.javacodegeeks.com/2012/03/is-copy-and-paste-programming-really.html