学编程复制粘贴害死人_复制和粘贴编程真的有问题吗？

最新推荐文章于 2023-05-30 03:56:52 发布

danpu0978

最新推荐文章于 2023-05-30 03:56:52 发布

阅读量884

点赞数

文章标签：编程语言 java python 设计模式人工智能

原文链接：https://www.javacodegeeks.com/2012/03/is-copy-and-paste-programming-really.html

版权

复制粘贴编程在节省时间和降低风险方面有其优势，尤其在代码起点和维护大型系统时。然而，随着复制内容的增多，维护成本增加，易引发问题。何时进行复制粘贴需要权衡，一般在第三次复制时应考虑重构。了解何时复制粘贴有意义以及何时成为问题，对于负责任的编程至关重要。

摘要由CSDN通过智能技术生成

学编程复制粘贴害死人

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

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

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

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

为什么要复制和粘贴？

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

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

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

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

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

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

现在复制和粘贴，并制定计划以供以后重新构建，甚至在必要时重新设计以实现通用解决方案是正确的方法。

当复制和粘贴有意义时

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

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

当复制和粘贴成为问题时

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

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

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

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

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

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

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

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

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

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