复制粘贴代码真的有问题吗？

当你编程的时候，复制和粘贴—将你现有的代码进行再利用，这是不必再重复编码的最佳做法。这是一个技术债务的最佳例子：偷懒，草率和目光短浅，这会让维护代码的长期成本增加。

但它同时也很自然，找一些已经在运行的代码，跟你所需要的非常像，复制，粘贴，并用它作为起点。几乎每个人都这么干过。因为有些时候，复制过来的代码不仅仅是方便，而且就算我们所需要的。

首先要清楚我讲得复制粘贴的意思。不是说从互联网上复制代码，我指的是程序员重用代码的捷径–当他们遇到的问题与他们之前在另外一个系统中遇到的问题类似的时候，他们开始用现有的代码副本，并加以改变。

在开发和设计阶段的早期，复制和粘贴并没有什么优势。代码和设计仍可塑的，这时系统需要做的是建立一套正确的抽象。这个时候没有什么好复制的。当在你开发的后期时，你已经有大量的代码，你需要维护庞大的系统，复制和粘贴就变得更加复杂。

为什么要复制粘贴？

程序员复制粘贴，因为这样可以节省时间。首先，你必须站在一个起点，你要知道你的代码要做什么事？你所要做的就是那里需要增加，哪里需要修改。你就 可以专注于理解不同点。这时你变得更加自由–你可以清理你不需要的代码。这一切都很主要。因为你可能不知道你需要保留的，你需要改变的，直到你进入更深的 层面。

复制和粘贴同样可以降低风险。如果你改变和扩展现有的代码，至少它运行了一段时间，通常是更安全的，并且成本较低。

如果你正在构建一个新的B2B客户界面，你会使用新的吗？通常会采用现有的接口，作为新的起点。然后看看那里需要改变，到年底的时候，你就有了2个接口，但通常需要一段的时间来理解这个代码是什么？

找到一个共同的设计，正确的抽象和变化，以支持不同的现实和异常处理。你最终的代码可能变得无法理解，难以维护，直到不得不改变—因为原来的设计没有预料到不同情况下的异常和扩展，重构只能到此结束，你需要一个全的设计和实施。

改变现有的代码，进行重构和扩展，将会让你目前的工作增加风险和成本，你不能为了适应网上的新客户而让给老客户带来问题。你需要格外的小心，你不但要明白你将要做的事每个细节（新界面），而且要明白现有界面的每个细节，它的行为和假设。

如果你认为这些改变都能被自动化测试工具捕捉到，那你就很天真了—假设你已经有良好的自动化测试工具，你需要整合现有的接口测试，这可能需要花费数周甚至数月的时间。让那些客户花费这么多的时间适应新界面，他们会不满意，因为他们都已经习惯了。

现在就复制粘贴，如果需要的话，过些日子要制定计划来重构和重新设计，是明智的选择。

什么时候该复制粘贴？

1.分叉 — 试探性的原因，如适应不同的平台或者硬件
2.模板 — 一些语言不支持某些库或者共享函数，这时有必要复制粘贴代码。
3.定制 — 临时的解决办法，只要是临时的。
4.微软克隆的做法 — 一个小组的代码给另外小组用。这时开源的通常做法，需要扩展来解决专有问题。

什么时候复制粘贴会变成问题？

什么时候复制粘贴会成为问题，有几个主要因素。

首先，你对你复制的代码理解程度是多少，你稳定程度如何，有多少潜在的bug。你总不想继承别人的问题吧。

还要知道这个代码已经拷贝了多少份？根据“三则重构”(three strikes and you refactor)原则。因为你复制了什么，并且加上改变，就带来维护上的问题。这个维护的困难就是如何理清问题，因为2个版本不足以理解哪些是共有的，哪些是特殊的。

越多次的拷贝，越多的维护上的问题。多个版本的更改和修正增加了维护的风险和成本。保持代码的同步，需要在多个系统中改变它。

虽然一些工具可以帮助你来寻找复制和粘贴的代码。随着时间的推移，不同的程序员寻找复制的副本代码变得更加艰难。有些程序员建议离职时做好复制标记，以便后来的程序员维护。

复制粘贴不是免费的。像软件里面的其它做法一样，它不是正确的或者是错误的，而是一个工具，你可以善用，也可以滥用。

意识到这些是非常重要的，假设我们有复制粘贴，我们必须为我们的工作负责。