有时，我的老板会向我们抱怨：
为什么我们需要这么长时间才能实现功能？
实际上，此功能之前已在其他应用程序中实现，您只需从那里复制并粘贴代码即可。成本应该很低。
这是一个很难的问题，因为在我看来，复制和粘贴代码并不是一件简单的事情。
你有充分的理由向非技术老板解释这个问题吗？
答案 0 :(得分：167)
如果您在复制粘贴代码中发现错误，则需要在每个地方修复它，并希望您能够记住它们（这也适用于更改的要求）。
如果您将逻辑保存在一个位置，则在需要时更容易更改（因此，如果您确定应用程序需要更新，则只能在一个位置进行更改）。
请老板阅读DRY principle（不要重复自己）。
您所描述的内容听起来像库的完美用途，您可以在其中共享代码并将其保存在一个位置。
如果我打算稍后重构，我只会复制粘贴代码 - 确保我稍后提取公共代码，以便尽可能多地重用逻辑。不久之后，我的意思是分钟和小时后，而不是几天和几周。
答案 1 :(得分：25)
通过构建库而不是使用复制和粘贴复制代码，共享代码会好得多。
你仍然可以获得速度优势而不是重写（查找DRY），但只有一个地方可以维护代码。
答案 2 :(得分：12)
显而易见的原因是你为未来承担了“债务”：你需要在代码中做出的任何改变（不仅仅是错误修正，任何改变）现在都要贵两倍，因为你必须更新两个地方 - 而且风险更大，因为你最终会忘记其中一个。换句话说，让它现在更快地工作将使你的工作在未来变得更慢，可以具有良好的商业意义，但通常不是。
但更重要的原因是“这与此相同”的假设往往是巧妙的错误。每当您的代码依赖于未说出的假设是正确的时，将其复制到另一个地方会导致错误，除非这些假设也适用于新的地方。因此，粘贴的代码从一开始就经常是错误的，而不是在下一次更改之后。
答案 3 :(得分：10)
设计方面，复制粘贴的代码肯定是一场灾难，未来可能会造成很多问题。但你问为什么现在需要你做很多工作，答案是：因为它不仅仅是复制和粘贴。
如果原始代码是为了重用而编写的，作为一个相当独立的库，考虑到灵活性和客户端使用 - 那么很好，但这不是复制粘贴，而是使用代码库。真正的代码复制粘贴通常更像是这样：
总之，不能直接使用的现有代码最多可以作为编写类似代码的良好参考。它当然不能被提升整体，并期望在一个完全不同的系统中工作。一般来说，一个安全的假设是，任何已编写和完成的代码都应该尽可能少地混淆 - 即使它是副本而不是原始本身。
如果你想让你的项目基于复制粘贴，你必须以一种能够轻松重用的方式编码开始，不用复制那个原始代码和搞乱它。这是值得做的，如果那是你老板所期待的，那么你们都需要确保这就是你设计和工作的方式。
答案 4 :(得分：9)
如果您已经实现了这些功能，并且需要进行复制和粘贴以重复使用它们，那么听起来您做错了。你不能把这些功能放在一个库中，这样你可以重复使用它们而无需复制/粘贴吗？
答案 5 :(得分：9)
复制和粘贴是一场等待发生的灾难。您的老板应该尽早评估运输价格，以及很快将代码发送给最终用户的价格。
答案 6 :(得分：8)
答案 7 :(得分：7)
对我来说，非技术老板最糟糕的误解是，你的工作主要是打字。他们认为你可以通过消除打字来节省大量时间。
我认为你能给予这个人最好的教育就是指出你所做的所有不打字的工作。即使大部分工作通常都是在您的头脑中，在打字的同时无形地发生。
当然，取消打字会节省一些时间。但是，随着时间的推移，你工作的大得多，不打字的部分会变得更大，随时都会吃掉。
答案 8 :(得分：4)
您确定您的老板想要了解DRY原则，错误和其他技术内容吗？
当您的老板或公司低估完成某个项目所需的时间时，您通常会听到这种评论。并且基于错误的估计，签订了合同等。在大多数情况下，程序员不参与估算。
为什么会这样？有时项目发起人的预算太少。也许您正在使用软件自动化的业务流程不值得您的团队努力。在这种情况下，经理通常会因坏消息而非常关闭。在项目开始时，有一厢情愿的想法。然后管理者试图责怪程序员。在您的情况下间接通过复制粘贴。在极端情况下，这称为a death march。
答案 9 :(得分：3)
复制和粘贴代码通常会导致Programming by Coincidence
答案 10 :(得分：3)
我认为“另一个应用程序”在这里是关键，如果其他应用程序已经过测试并且在使用中，它应该不能更改以使用公共库，因此你无法与它共享代码。
在相同的应用程序中，“复制和粘贴”很糟糕，但是在不同团队开发或具有不同发布周期的“复制和粘贴”代码库之间可能是最佳选择。
答案 11 :(得分：2)
即使其他应用程序已经具有您需要的功能，该功能的代码可能根本不适合您当前的应用程序而无需重大改写。这就像乘坐福特汽车并试图将其装入丰田汽车。一般来说，有一条经验法则，如果你必须修改超过25％的代码，那么从头开始重写它会更好（更便宜）。
将有问题的代码提取到一个引人注目的库中，但它可能比听起来更难，这取决于其他系统的构建方式。例如。该功能的代码可能很难提取，因为它以不干净的方式连接了许多其他代码（例如，通过访问许多全局变量等）。
答案 12 :(得分：2)
我曾在一家类似的公司工作过。作为一名实习生，我当时并不知道，所以当我开始一个新项目时，我的老板还建议从其他地方粘贴代码。好吧，正如你可能想的那样，整个软件都非常混乱，直到你试图修复一个bug时，出现了两个新bug。
答案 13 :(得分：1)
告诉你的老板，每个变量名称的一部分都包含旧项目的名称，现在你必须手动更改它们。如果你的老板不知道（或想知道）为什么复制/粘贴不好他/她可能会相信：）
答案 14 :(得分：1)
在您面前的直接功能的开发速度（特别是在应用程序很小时）与应用程序增长时的长期维护成本之间存在权衡。
复制和粘贴对于即时功能来说更快，但随着应用程序规模的扩大，在修复错误和进行系统范围的更改以及维护应用程序的不同组件之间的工作流程方面，您将付出沉重的代价。
这是企业主需要听到的论点。它类似于维护车队的公认成本，但是，使用软件，软件架构的破坏方面通常对业务方面是隐藏的，并且只能由开发人员看到。
答案 15 :(得分：0)
他是对的，如果团队之前已经实现了类似的功能，第二次重复它将会更容易 。
但是，您应该解释每个应用程序是不同的。仅仅因为你在一个房子里安装了一扇门并不意味着你可以在另一个房子里安装另一扇门没时间停放 - 你会因为经验（＃doors安装）而更快，但它会仍然需要时间来装备你的设备，安装门，确保它是垂直的，并将其拧入框架中。
答案 16 :(得分：0)
是的，最大的问题是它不只是复制和粘贴 - 然后粘贴然后粘贴然后稍微修改。
然后，当其中一个粘贴的变体出现问题时，它会发生变化。然后，另一个变种会发生变化。
然后，您发现所有变体都必须更改，因为原始副本有错误。现在你很好并且真正搞砸了，因为所有粘贴的区域现在都不一样了。
你不知道吗，这种糟糕的编码通常几乎完全没有评论。
对我来说，区别在于当你有多个代码副本做同样的事情时，你拥有的是一堆代码。当你只有一段代码执行每个特定的事情时，你就有了一个系统。
系统的行为可以通过单点修改很容易地改变 - 改变一堆代码的行为需要一堆代码。
我喜欢系统，而不是一堆代码。
答案 17 :(得分：0)
在我的公司，我们总是使用类和方法，并为他们制作技术文档。我认为这是最佳实践，如果您可以使用自己的svn搜索应用程序和好的密钥来查找之前使用的方法类：）