If you find a bug in your copy-paste code, you will need to fix it every place you did and hope you can remember them all (this also holds for changed requirements).
If you keep logic in one place, it is easier to change when needed (so if you decide that the application needs updating, you only do it in one place).
Have your boss read about the DRY principle (Don't Repeat Yourself).
What you are describing sounds like the perfect use for libraries, where you share code and only keep it in one place.
I would only ever copy-paste code if I intended to refactor it soon after - making sure I later on extracted common code so I could reuse as much logic as possible. And by soon after, I mean minutes and hours later, not days and weeks.
The obvious reason is that you take on a 'debt' for the future: any change you ever need to make in the code (not just bugfixes, any change) will now be twice as expensive to do because you have to update two places - and more risky because you WILL forget one of them eventually. In other words, making it work faster now will make your work even slower in the future, which can be good business sense but usually isn't.
But the more important reason is that the assumption "this is the same as that" is more often than not subtly wrong. Whenever your code depends on unspoken assumptions to be correct, copying it into another place results in errors unless these assumptions also hold in the new place. Therefore, the pasted code is often wrong from the start and not just after the next change.
Design-wise, copy-pasted code is certainly a disaster, with the potential to cause lots of problems in the future. But you're asking why it takes you a lot of work right now, the answer is: because it's never just copying and pasting.
If the original code was written in order to be reused, as a fairly independent library, with flexibility and client use in mind - then great, but that's not copy-pasting, that's using a code library. Real code copy-pasting usually goes more like this:
"Sure, I've already got code that does exactly that!"
"Wait, which of these five versions of code is the one I want to use as my source?"
"Hmmm, what do all these 'util_func_023' functions do? Didn't I document them? Which of them do I need now?"
"Oh, yeah, this code uses Code Base Y. Guess I need to [choose one: copy all of Code Base Y into my new project / spend a day extricating the one function I want from Code Base Y / spend a week extricating the one function I want from Code Base Y]."
"I copied everything, yay!"
"Why isn't this working?"
This is the point where you spend hours/days/weeks debugging existing code that is similar to what you want, instead of writing the code you actually want to begin with.
In summary, existing code which can't be used directly can, at best, serve as a good reference for writing similar code. It certainly can't be lifted whole and expected to work in a completely different system. In general, it's a safe assumption that any code which has been written and completed, should be messed with as little as possible - even when it's a copy and not the original itself.
If you want to base your project on copy-pasting, you've got to code to begin with in a manner that will enable easy reuse, without copying that original code and messing around with it. That's worth doing, and if that's what your boss is expecting, then you both need to make sure that that's how you design and work in the first place.
copy and pasting is a disaster waiting to happen. Your boss should evaluate the price of shipping early with respect to the price of having broken code shipped to the end-user very soon.
If you have already implemented the features and you need to copy and paste to reuse them, it sounds like you have done something wrong. Can't you put these features in a library so you can reuse them without copy/paste?
It sounds to me like the worst misconception your non-technical boss has, is that your job is predominantly typing. They think you can save a lot of time by eliminating typing.
I think the best education you could give this person is to point out all of the work you do that isn't typing. Even if most of that work usually happens invisibly, in your head, at the same time as typing.
Sure, eliminating the typing will save some time. But then the much larger, non-typing, part of your job gets bigger and eats up any time saving and more besides.
Are you sure your boss wants to hear about DRY principle, bugs and other tech stuff?
That kind of comments you usually hear when your boss or company underestimated time needed to complete some project. And based on wrong estimation a contract was signed, etc. In most cases programmers weren't involved into estimations.
Why this happens? Sometimes project sponsor has too small budget. Maybe a business process you are automating using software isn't worth your team effort. Managers generally tend to be very closed for bad news in such cases. At the beginning of the project there is wishful thinking. Then managers try to blame programmers. In your case indirectly via copy-and-paste. In extreme cases this is called a death march.
I think "another application" is key here, if the other application is already tested and in use, it should not be changed to use a common library, therefore you can’t share code with it.
Within the same application, “copy and paste” is bad, but between code bases that are developed by different teams or with different release cycles “copy and paste” can be the best option.
I worked for a similar company. Being a trainee, I didn't know better then, so when I started a new project, my boss also suggested to paste the code from somewhere else. Well, as you may think, the whole software was quite a mess, up to the point that when you tried to fix a bug, two new bugs appeared.
Even if the other application already has the feature you need, the code for that feature might simply not fit into your current application without a major rewrite. It's like taking the motor of a Ford and trying to fit it into a Toyota. Generally, there is a rule of thumb that if you have to modify more than 25% of the code you copy, it's better (cheaper) to rewrite it from scratch.
Extracting the code in question into a library sound compelling, but it might be more difficult than it sounds, depending on how that other system is built. E.g. the code for that feature might be hard to extract because it interfaces a lot of other code in unclean ways (e.g. by accessing lots of global variables etc.)
There are trade-offs between speed of development of the immediate functionality in front of you (especially when the application is small), and longer term maintenance costs as the application grows.
Copy and paste is quicker for the immediate functionality, but will costs you dearly as the application grows in size, in terms of fixing bugs and making system wide changes and maintaining workflows between different components of the application.
That is the argument that business owners need to hear. It is similar to the accepted costs of maintaining a fleet of vehicles, however, with software, the broken aspects of the software architecture are generally hidden to the business side, and can only be seen by developers.
Tell your boss that the part of the each and every variable name includes the name of the old project and now you have to change them all, manually. If your boss doesn't know (or wants to know) why copy/paste is bad he/she might as well believe that :)
Yeah, the biggest problem is that it isn't just copy and paste - its copy then paste then slightly modify.
Then later on when one of the pasted variants has a problem, it gets changed. Then later on, another variant gets changed.
Then, you find out that all the variants have to change cause the original copy had bugs. Now you are well and truly screwed because all the pasted areas are now not the same.
And wouldn't you know it, this kind of crappy coding is usually almost entirely void of comments.
To me, the difference is that when you have multiple copies of code doing the same thing, what you have is a bunch of code. When you only have one piece of code doing each particular thing, then you have a system.
Behaviors of a system can be changed with single point modifications quite easily - changing the behavior of a bunch of code requires a bunch of code.
He's right that if the team has implemented similar functionality before, repeating it will be much easier the 2nd time.
However, you should probably explain that each application is different. Just because you installed a door in one house doesn't mean you can install another door in another house in no time flat - you will be faster because of the experience (# doors installed), but it will still take time to get you equipment, mount the door, make sure it is plumb, and screw it into the frame.
in my company, we always work with classes and methods, and make technical documentation for them. I think its the best practice if u can use your own svn search aplications with good keys to find method class used before :)
发布评论
评论（18）
如果您在复制粘贴代码中发现错误，您将需要修复您所做的每个地方，并希望您能记住所有这些（这也适用于更改的需求）。
如果将逻辑保留在一处，则在需要时更容易更改（因此，如果您决定应用程序需要更新，则只需在一处进行即可）。
让您的老板了解DRY 原则（不要重复自己）。
您所描述的内容听起来像是库的完美使用，您可以在其中共享代码并仅将其保存在一个地方。
如果我打算很快重构它，我只会复制粘贴代码 - 确保我稍后提取公共代码，以便我可以重用尽可能多的逻辑。不久之后，我的意思是几分钟和几小时后，而不是几天和几周后。
If you find a bug in your copy-paste code, you will need to fix it every place you did and hope you can remember them all (this also holds for changed requirements).
If you keep logic in one place, it is easier to change when needed (so if you decide that the application needs updating, you only do it in one place).
Have your boss read about the DRY principle (Don't Repeat Yourself).
What you are describing sounds like the perfect use for libraries, where you share code and only keep it in one place.
I would only ever copy-paste code if I intended to refactor it soon after - making sure I later on extracted common code so I could reuse as much logic as possible. And by soon after, I mean minutes and hours later, not days and weeks.
通过构建库来共享代码，比使用复制和粘贴复制代码要好得多。
与重写（查找 DRY）相比，您仍然可以获得速度优势，但只有一个地方可以维护代码。
You would be far better off sharing the code by building a library rather than copying the code using copy and paste.
You'll still gain a speed advantage over re-writing (look up DRY) but will only have one place to maintain the code.
明显的原因是你为未来承担了“债务”：你需要在代码中进行的任何更改（不仅仅是错误修复，任何更改）现在都将花费两倍的成本，因为你必须更新两个地方 -而且风险更大，因为你最终会忘记其中一个。换句话说，现在让它工作得更快将使您将来的工作变得更慢，这可能是良好的商业意识，但通常并非如此。
但更重要的原因是“这与那相同”的假设往往是微妙的错误。每当您的代码依赖于不言而喻的假设来确保正确时，将其复制到另一个位置就会导致错误，除非这些假设在新位置也成立。因此，粘贴的代码通常从一开始就是错误的，而不仅仅是在下一次更改之后。
The obvious reason is that you take on a 'debt' for the future: any change you ever need to make in the code (not just bugfixes, any change) will now be twice as expensive to do because you have to update two places - and more risky because you WILL forget one of them eventually. In other words, making it work faster now will make your work even slower in the future, which can be good business sense but usually isn't.
But the more important reason is that the assumption "this is the same as that" is more often than not subtly wrong. Whenever your code depends on unspoken assumptions to be correct, copying it into another place results in errors unless these assumptions also hold in the new place. Therefore, the pasted code is often wrong from the start and not just after the next change.
从设计角度来看，复制粘贴的代码无疑是一场灾难，有可能在未来引起很多问题。但您问为什么现在需要大量工作，答案是：因为它不仅仅是复制和粘贴。
如果原始代码是为了重用而编写的，作为一个相当独立的库，考虑到灵活性和客户端使用 - 那就太好了，但这不是复制粘贴，而是使用代码库。真正的代码复制粘贴通常更像是这样：
综上所述，现有的不能直接使用的代码最多只能作为编写类似代码的一个很好的参考。它当然不能被整体提升并期望在完全不同的系统中工作。一般来说，一个安全的假设是，任何已编写和完成的代码都应该尽可能少地受到干扰 - 即使它是副本而不是原始代码本身。
如果您想让您的项目基于复制粘贴，您必须以易于重用的方式开始编写代码，无需复制原始代码并摆弄它。这是值得做的，如果这是你的老板所期望的，那么你们都需要确保这就是你们设计和工作的方式。
Design-wise, copy-pasted code is certainly a disaster, with the potential to cause lots of problems in the future. But you're asking why it takes you a lot of work right now, the answer is: because it's never just copying and pasting.
If the original code was written in order to be reused, as a fairly independent library, with flexibility and client use in mind - then great, but that's not copy-pasting, that's using a code library. Real code copy-pasting usually goes more like this:
In summary, existing code which can't be used directly can, at best, serve as a good reference for writing similar code. It certainly can't be lifted whole and expected to work in a completely different system. In general, it's a safe assumption that any code which has been written and completed, should be messed with as little as possible - even when it's a copy and not the original itself.
If you want to base your project on copy-pasting, you've got to code to begin with in a manner that will enable easy reuse, without copying that original code and messing around with it. That's worth doing, and if that's what your boss is expecting, then you both need to make sure that that's how you design and work in the first place.
复制和粘贴是一场即将发生的灾难。您的老板应该尽早评估运输价格以及很快将损坏的代码发送给最终用户的价格。
copy and pasting is a disaster waiting to happen. Your boss should evaluate the price of shipping early with respect to the price of having broken code shipped to the end-user very soon.
如果您已经实现了这些功能，并且需要复制并粘贴才能重用它们，那么听起来您好像做错了什么。您不能将这些功能放入库中以便无需复制/粘贴即可重用它们吗？
If you have already implemented the features and you need to copy and paste to reuse them, it sounds like you have done something wrong. Can't you put these features in a library so you can reuse them without copy/paste?
DRY 原则（不要重复自己）：
维基百科上的干燥。
其他链接。
The DRY principle (Don't Repeat Yourself):
DRY on wikipedia.
other link.
在我看来，你的非技术老板最严重的误解是，你的工作主要是打字。他们认为通过消除打字可以节省大量时间。
我认为你能给这个人最好的教育就是指出你所做的所有非打字工作。即使大部分工作通常在打字的同时在您的脑海中无形地发生。
当然，消除打字会节省一些时间。但随后，你的工作中更大的、非打字的部分就会变得更大，并消耗掉你节省下来的时间和更多。
It sounds to me like the worst misconception your non-technical boss has, is that your job is predominantly typing. They think you can save a lot of time by eliminating typing.
I think the best education you could give this person is to point out all of the work you do that isn't typing. Even if most of that work usually happens invisibly, in your head, at the same time as typing.
Sure, eliminating the typing will save some time. But then the much larger, non-typing, part of your job gets bigger and eats up any time saving and more besides.
您确定您的老板想了解 DRY 原则、错误和其他技术内容吗？
当你的老板或公司低估了完成某个项目所需的时间时，你通常会听到这种评论。并且基于错误的估计签订了合同，等等。在大多数情况下，程序员不参与估计。
为什么会出现这种情况？有时项目发起人的预算太少。也许您使用软件自动化的业务流程不值得您的团队付出努力。在这种情况下，管理者通常对坏消息非常封闭。项目之初存在着一厢情愿的想法。然后经理们试图责怪程序员。在您的情况下，通过复制和粘贴间接进行。在极端情况下，这被称为死亡行军。
Are you sure your boss wants to hear about DRY principle, bugs and other tech stuff?
That kind of comments you usually hear when your boss or company underestimated time needed to complete some project. And based on wrong estimation a contract was signed, etc. In most cases programmers weren't involved into estimations.
Why this happens? Sometimes project sponsor has too small budget. Maybe a business process you are automating using software isn't worth your team effort. Managers generally tend to be very closed for bad news in such cases. At the beginning of the project there is wishful thinking. Then managers try to blame programmers. In your case indirectly via copy-and-paste. In extreme cases this is called a death march.
复制和粘贴代码通常会导致巧合编程
Copying and pasting code usually leads to Programming by Coincidence
我认为“另一个应用程序”是这里的关键，如果另一个应用程序已经经过测试并正在使用，则不应将其更改以使用通用库，因此您可以'不要与它共享代码。
在同一个应用程序中，“复制和粘贴”是不好的，但在不同团队开发的代码库或具有不同发布周期的代码库之间，“复制和粘贴”可能是最好的选择。
I think "another application" is key here, if the other application is already tested and in use, it should not be changed to use a common library, therefore you can’t share code with it.
Within the same application, “copy and paste” is bad, but between code bases that are developed by different teams or with different release cycles “copy and paste” can be the best option.
我曾在一家类似的公司工作过。作为一名实习生，我当时还不太了解，所以当我开始一个新项目时，我的老板也建议从其他地方粘贴代码。好吧，正如您可能认为的那样，整个软件非常混乱，以至于当您尝试修复错误时，出现了两个新错误。
I worked for a similar company. Being a trainee, I didn't know better then, so when I started a new project, my boss also suggested to paste the code from somewhere else. Well, as you may think, the whole software was quite a mess, up to the point that when you tried to fix a bug, two new bugs appeared.
即使其他应用程序已经具有您需要的功能，如果不进行重大重写，该功能的代码也可能根本不适合您当前的应用程序。这就像把福特汽车的发动机装进丰田汽车一样。一般来说，有一条经验法则是，如果您必须修改超过 25% 的复制代码，那么最好（更便宜）从头开始重写。
将有问题的代码提取到库中听起来很引人注目，但它可能比听起来更困难，具体取决于其他系统的构建方式。例如，该功能的代码可能很难提取，因为它以不干净的方式连接了许多其他代码（例如，通过访问大量全局变量等）
Even if the other application already has the feature you need, the code for that feature might simply not fit into your current application without a major rewrite. It's like taking the motor of a Ford and trying to fit it into a Toyota. Generally, there is a rule of thumb that if you have to modify more than 25% of the code you copy, it's better (cheaper) to rewrite it from scratch.
Extracting the code in question into a library sound compelling, but it might be more difficult than it sounds, depending on how that other system is built. E.g. the code for that feature might be hard to extract because it interfaces a lot of other code in unclean ways (e.g. by accessing lots of global variables etc.)
您面前的即时功能的开发速度（特别是当应用程序很小时）与随着应用程序的增长而产生的长期维护成本之间存在权衡。
对于即时功能而言，复制和粘贴速度更快，但随着应用程序规模的增大，在修复错误、进行系统范围的更改以及维护应用程序不同组件之间的工作流程方面，您将付出高昂的代价。
这是企业主需要听到的论点。它类似于维护车队的可接受成本，但是对于软件来说，软件架构的损坏方面通常对业务方隐藏，只有开发人员才能看到。
There are trade-offs between speed of development of the immediate functionality in front of you (especially when the application is small), and longer term maintenance costs as the application grows.
Copy and paste is quicker for the immediate functionality, but will costs you dearly as the application grows in size, in terms of fixing bugs and making system wide changes and maintaining workflows between different components of the application.
That is the argument that business owners need to hear. It is similar to the accepted costs of maintaining a fleet of vehicles, however, with software, the broken aspects of the software architecture are generally hidden to the business side, and can only be seen by developers.
告诉你的老板，每个变量名称的一部分都包含旧项目的名称，现在你必须手动更改它们。如果你的老板不知道（或想知道）为什么复制/粘贴不好，他/她不妨相信:)
Tell your boss that the part of the each and every variable name includes the name of the old project and now you have to change them all, manually. If your boss doesn't know (or wants to know) why copy/paste is bad he/she might as well believe that :)
是的，最大的问题是它不仅仅是复制和粘贴 - 它是复制然后粘贴然后稍微修改。
然后，当粘贴的变体之一出现问题时，它就会被更改。后来，另一个变体发生了变化。
然后，您发现所有变体都必须更改，因为原始副本存在错误。现在你真的完蛋了，因为所有粘贴的区域现在都不一样了。
你难道不知道吗，这种蹩脚的编码通常几乎完全没有注释。
对我来说，不同之处在于，当你有多个代码副本做同样的事情时，你所拥有的是一堆代码。当你只有一段代码来完成每一件特定的事情时，你就拥有了一个系统。
系统的行为可以很容易地通过单点修改来改变——改变一堆代码的行为需要一堆代码。
我喜欢系统，而不是一堆代码。
Yeah, the biggest problem is that it isn't just copy and paste - its copy then paste then slightly modify.
Then later on when one of the pasted variants has a problem, it gets changed. Then later on, another variant gets changed.
Then, you find out that all the variants have to change cause the original copy had bugs. Now you are well and truly screwed because all the pasted areas are now not the same.
And wouldn't you know it, this kind of crappy coding is usually almost entirely void of comments.
To me, the difference is that when you have multiple copies of code doing the same thing, what you have is a bunch of code. When you only have one piece of code doing each particular thing, then you have a system.
Behaviors of a system can be changed with single point modifications quite easily - changing the behavior of a bunch of code requires a bunch of code.
I like systems, not a bunch of code.
他是对的，如果团队以前实现过类似的功能，那么第二次重复它会容易容易。
但是，您可能应该解释一下每个应用程序都是不同的。仅仅因为您在一所房子里安装了一扇门，并不意味着您可以在另一所房子里安装另一扇门，没有时间 - 由于经验，您会更快（安装了 # 扇门），但它会仍然需要时间来获取设备，安装门，确保其垂直，然后将其拧入框架。
He's right that if the team has implemented similar functionality before, repeating it will be much easier the 2nd time.
However, you should probably explain that each application is different. Just because you installed a door in one house doesn't mean you can install another door in another house in no time flat - you will be faster because of the experience (# doors installed), but it will still take time to get you equipment, mount the door, make sure it is plumb, and screw it into the frame.
在我的公司，我们总是使用类和方法，并为它们制作技术文档。我认为如果你可以使用你自己的 svn 搜索应用程序和好的键来查找之前使用的方法类，这是最好的做法:)
in my company, we always work with classes and methods, and make technical documentation for them. I think its the best practice if u can use your own svn search aplications with good keys to find method class used before :)