Your co-worker is optimizing his short term effectiveness by sacrificing the longer term effectiveness of the organization (e.g., the rest of his co-workers as well as himself). Any changes required in the first file are likely required in the second one, but nobody will remember... and that will cause 2 cycles of find and fix, rather than one.
You could run a clone detector over the code and simply exhibit the results to his manager.
You can see samples of clone detecion for various languages using our CloneDR detector. It is designed to find an detect big blocks of code with consistent renames and it can show exactly what happened.
He's probably assuming that it aint broke, and won't be. Also, the perfect is the enemy of the good. I don't think he's oblivious to the dangers of copy/paste, he just has a different assessment of the potential for error than you.
Perhaps you could break it for him, to show how easy it is. If you can't, perhaps he's right.
There are lots of valid reasons not to duplicate the code, but just ask... does your team want to maintain 100K lines of code (with code duplications), or 50K lines of code? It may seem code duplication at this point is minimal, which is why your coworker doesn't see the importance of DRY concept, but imagine if s/he duplicates more and more code for the next 5 years. Who is going to maintain that code? Your team? What if s/he leaves the job one day? Do your team want to maintain this crap? :) If not, then you already made a very compelling case not to duplicate the code, not to mention "more duplications" = "more prone to having more bugs in the future".
Appeal to your boss on technical grounds. If the boss agrees with your colleague's methods/and/or doesn't make him fix it, then there aint much you can do if appealing to reason doesn't work.
Tell him that you never know where an application can go in a business... A simple test application can sometimes get modified over and over, and finally end up being used a lot... I've seen this often in small companies. And then, instead of starting everyting over and waste time on things that could have been fixed before, you could simply do it now, short and sweet, while it can be...
It is not about making your friend fix this right now. It is about growing your team.
Make him realize that he is being unfair to the team & the project. If he is still not agreeing to it, get him a cup of coffee and ask him to sit by sipping it, while you could take on his keyboard and actually fix the code in front of him.
He might get ashamed and not do it next time(big win). I have used this 4 times and it has always worked!
If he is superior (or supervisor) to you, ask more explanations - its possible to know more about the context... maybe doesnt worth to refactor the code (maybe is a small project).
If he is equal to you, you can report to your superior, by proposing this solution (which is a better one).
If you are superior to him, just "ask" him to do your way...
First, acknowledge that he's right: copy-paste is indeed faster now.
Then, say that the problem is the cost in the long run, and that the cost will increase because with duplication, the system isn't as well-ordered as it could be. He's introducing disorder, clutter, and the more disorder you have, the harder it is to work with a system. Applying some effort now to organize it better will (usually) pay off in the long term. It's just like keeping your desk or room organized.
Hay, this is from the year 2022. Code duplication is not always bad. Perhaps your colleague duplicating the code have a different perspective, and maybe he/she/they are correct.
Good software engineering happens by thinking in different viewpoints and focusing on the journey towards the target state vision. Software engineering best practices are a small part of that journey. Here is the link to a wonderful and very interesting talk about code duplication. https://www.deconstructconf.com/2019/dan-abramov-the-wet-codebase
What worries me a bit is that so many people in these answers to this question strongly believe that code duplication is always wrong, which impales that someone who stated an excellent rational and logical argument today or a decade ago got humiliated.
Our thought processes and ideas are worth more than any software engineering best practices, no matter how controversial they are. Build on top of others' ideas.
When he desires coffee, make him get it one sip at a time from the coffee pot instead of an entire cup. This is especially effective if he adds cream and sugar which will have to be dolled out in minuscule portions. This should illustrate how repetitive tasks are very cumbersome and tiring (like correcting 20 pieces of code rather than one).
Then, send him a link to this posting so he can see all the other people that have your back.
He's a rational person that simply doesn't have too much experience. In this case, you can possibly rationalize your argument, maybe by showing him a clearer example of code duplication someone else in your code. You can also find a bug in the original copy (or even better, a few bugs), and tell him now his code IS broken and he must fix it.
He's a stubborn ass: Then you should not waste energy on him. Go to his boss and let the boss take care of it. Some people are just like that.
While the first option is obviously much better, sometimes you don't have a choice. And if you will be the one who will eventually need to maintain his code at 3AM in the morning because some important client starts shouting on the other side of the earth - then it's definitely your problem, and your boss should handle it.
And finally, if your boss thinks you're wrong, you're probably in the wrong place.
发布评论
评论（15）
给他一份重构。
Give him a copy of Refactoring.
改进你的代码版本，以至于他因嫉妒而感到沮丧，然后说 - 如果你刚刚链接到我的代码......
Improve your version of the code so much that he is frustrated with jealousy, then say - if you had just linked to my code...
你的同事正在通过牺牲长期效益来优化他的短期效率
组织的长期有效性（例如，他的其他同事以及
作为他自己）。第一个文件中所需的任何更改
第二个可能需要，但没有人会记得......并且
这将导致 2 个查找和修复周期，而不是 1 个周期。
您可以对代码运行克隆检测器，然后将结果简单地展示给他的经理。
有关列表，请参阅有关重复代码的维基百科。
您可以使用我们的 CloneDR 检测器查看各种语言的克隆检测示例。它被设计
找到一个检测具有一致重命名的大代码块，它可以
准确地显示发生了什么。
Your co-worker is optimizing his short term effectiveness by sacrificing the longer
term effectiveness of the organization (e.g., the rest of his co-workers as well
as himself). Any changes required in the first file
are likely required in the second one, but nobody will remember... and
that will cause 2 cycles of find and fix, rather than one.
You could run a clone detector over the code and simply exhibit the results to his manager.
See Wikipedia on duplicate code for a list.
You can see samples of clone detecion for various languages using our CloneDR detector. It is designed
to find an detect big blocks of code with consistent renames and it can
show exactly what happened.
他可能认为它没有坏，也不会坏。而且，完美是优秀的敌人。我不认为他没有意识到复制/粘贴的危险，他只是对潜在错误的评估与你不同。
也许你可以帮他打破它，以表明它是多么容易。如果你不能，也许他是对的。
He's probably assuming that it aint broke, and won't be. Also, the perfect is the enemy of the good. I don't think he's oblivious to the dangers of copy/paste, he just has a different assessment of the potential for error than you.
Perhaps you could break it for him, to show how easy it is. If you can't, perhaps he's right.
有很多正当的理由不重复代码，但只是问...您的团队想要维护 100K 行代码（包含代码重复）还是 50K 行代码？此时，代码重复似乎很少，这就是为什么您的同事没有看到 DRY 概念的重要性，但想象一下，如果他/她在接下来的 5 年内重复越来越多的代码。谁来维护该代码？你的团队？如果他/她有一天离职怎么办？你的团队想维持这种垃圾吗？ :) 如果没有，那么您已经提出了一个非常令人信服的理由，不要重复代码，更不用说“更多重复”=“将来更容易出现更多错误”。
There are lots of valid reasons not to duplicate the code, but just ask... does your team want to maintain 100K lines of code (with code duplications), or 50K lines of code? It may seem code duplication at this point is minimal, which is why your coworker doesn't see the importance of DRY concept, but imagine if s/he duplicates more and more code for the next 5 years. Who is going to maintain that code? Your team? What if s/he leaves the job one day? Do your team want to maintain this crap? :) If not, then you already made a very compelling case not to duplicate the code, not to mention "more duplications" = "more prone to having more bugs in the future".
因为当你发现一个bug时，你需要在两个地方进行更改。因为当你想要添加一个新功能时，你需要在两个地方添加它。
Because when you find a bug, you need to change it in two places. Because when you want to add a new feature, you need to add it in two places.
以技术理由向你的老板提出上诉。如果老板同意你同事的方法/和/或不让他解决问题，那么如果诉诸理性不起作用，你就无能为力。
Appeal to your boss on technical grounds. If the boss agrees with your colleague's methods/and/or doesn't make him fix it, then there aint much you can do if appealing to reason doesn't work.
告诉他，你永远不知道应用程序可以在企业中走向何方...一个简单的测试应用程序有时可能会被一遍又一遍地修改，最后最终被大量使用...我在小公司中经常看到这种情况。然后，你不必从头开始，把时间浪费在以前可以解决的事情上，你可以现在就做，简短而甜蜜，虽然它可以......
Tell him that you never know where an application can go in a business... A simple test application can sometimes get modified over and over, and finally end up being used a lot... I've seen this often in small companies. And then, instead of starting everyting over and waste time on things that could have been fixed before, you could simply do it now, short and sweet, while it can be...
这并不是要让你的朋友立即解决这个问题。这是关于发展你的团队。
让他意识到他对球队不公平。该项目。如果他仍然不同意，请给他一杯咖啡，让他坐下来喝咖啡，而你可以拿起他的键盘，在他面前实际修复代码。
他可能会感到羞愧，下次不再这样做（大胜利）。我已经用了 4 次了，一直有效！
祝你好运。
It is not about making your friend fix this right now. It is about growing your team.
Make him realize that he is being unfair to the team & the project. If he is still not agreeing to it, get him a cup of coffee and ask him to sit by sipping it, while you could take on his keyboard and actually fix the code in front of him.
He might get ashamed and not do it next time(big win). I have used this 4 times and it has always worked!
Good luck.
如果他是你的上级（或主管），请询问更多解释 - 有可能了解更多有关上下文的信息......也许不值得重构代码（也许是一个小项目）。
如果他和你平等，你可以向上级汇报，提出这个解决方案（这是一个更好的方案）。
如果你比他优秀，就“要求”他按照你的方式去做......
If he is superior (or supervisor) to you, ask more explanations - its possible to know more about the context... maybe doesnt worth to refactor the code (maybe is a small project).
If he is equal to you, you can report to your superior, by proposing this solution (which is a better one).
If you are superior to him, just "ask" him to do your way...
首先，承认他是对的：复制粘贴现在确实更快了。
然后，假设问题是从长远来看成本，并且成本将会增加，因为随着重复，系统的秩序可能不那么良好。他引入了无序、杂乱，无序越多，使用系统就越困难。现在付出一些努力来更好地组织它（通常）从长远来看会得到回报。这就像让你的办公桌或房间井井有条一样。
这是 Ivar Jakobson 的软件熵的想法
First, acknowledge that he's right: copy-paste is indeed faster now.
Then, say that the problem is the cost in the long run, and that the cost will increase because with duplication, the system isn't as well-ordered as it could be. He's introducing disorder, clutter, and the more disorder you have, the harder it is to work with a system. Applying some effort now to organize it better will (usually) pay off in the long term. It's just like keeping your desk or room organized.
This is Ivar Jakobson's idea of software entropy
嘿，这是 2022 年的事情。代码重复并不总是坏事。也许你的复制代码的同事有不同的观点，也许他/她/他们是正确的。
好的软件工程是通过从不同的角度思考并专注于实现目标状态愿景的过程来实现的。软件工程最佳实践只是这一旅程的一小部分。
这是关于代码重复的精彩且非常有趣的演讲的链接。 https://www.deconstructconf.com/2019/dan-abramov- the-wet-codebase
让我有点担心的是，在这个问题的答案中，很多人都坚信代码重复总是错误的，这刺痛了那些在今天或十年里提出了出色的理性和逻辑论证的人以前受过羞辱。
我们的思维过程和想法比任何软件工程最佳实践都更有价值，无论它们有多么有争议。建立在别人的想法之上。
Hay, this is from the year 2022. Code duplication is not always bad. Perhaps your colleague duplicating the code have a different perspective, and maybe he/she/they are correct.
Good software engineering happens by thinking in different viewpoints and focusing on the journey towards the target state vision. Software engineering best practices are a small part of that journey.
Here is the link to a wonderful and very interesting talk about code duplication. https://www.deconstructconf.com/2019/dan-abramov-the-wet-codebase
What worries me a bit is that so many people in these answers to this question strongly believe that code duplication is always wrong, which impales that someone who stated an excellent rational and logical argument today or a decade ago got humiliated.
Our thought processes and ideas are worth more than any software engineering best practices, no matter how controversial they are. Build on top of others' ideas.
问他当他发现代码中存在错误时他会做什么。他现在需要修复多少地方？
您还可以向他展示这个问题的答案（为什么代码的“复制和粘贴”危险吗？）。
Ask him what will he do when he finds a bug in his code. How many places will he now need to fix it in?
You can also show him the answers to this question (Why is “copy and paste” of code dangerous?).
当他想喝咖啡时，让他从咖啡壶里一次一小口地喝，而不是一整杯。如果他添加奶油和糖，这将特别有效，而奶油和糖必须以极小的份量进行分配。 这应该说明重复性任务是多么繁琐和累人（例如纠正 20 段代码而不是 1 段）。
然后，向他发送此帖子的链接，以便他可以看到所有其他拥有您的代码的人后退。
When he desires coffee, make him get it one sip at a time from the coffee pot instead of an entire cup. This is especially effective if he adds cream and sugar which will have to be dolled out in minuscule portions. This should illustrate how repetitive tasks are very cumbersome and tiring (like correcting 20 pieces of code rather than one).
Then, send him a link to this posting so he can see all the other people that have your back.
这里有两个选择：
他是一个理性的人，只是没有太多经验。在这种情况下，您可以通过向他展示一个更清晰的代码重复示例来合理化您的论点。您还可以在原始副本中找到一个错误（或者更好的是，一些错误），并告诉他现在他的代码已损坏，他必须修复它。
他是个顽固的混蛋：那你就不应该在他身上浪费精力。去找他的老板，让老板去处理。有些人就是这样。
虽然第一个选择显然要好得多，但有时您别无选择。如果你最终需要在凌晨 3 点维护他的代码，因为一些重要的客户开始在地球的另一边大喊大叫 - 那么这绝对是你的问题，你的老板应该处理它。
最后，如果你的老板认为你错了，那么你可能来错地方了。
There are two options here:
He's a rational person that simply doesn't have too much experience. In this case, you can possibly rationalize your argument, maybe by showing him a clearer example of code duplication someone else in your code. You can also find a bug in the original copy (or even better, a few bugs), and tell him now his code IS broken and he must fix it.
He's a stubborn ass: Then you should not waste energy on him. Go to his boss and let the boss take care of it. Some people are just like that.
While the first option is obviously much better, sometimes you don't have a choice. And if you will be the one who will eventually need to maintain his code at 3AM in the morning because some important client starts shouting on the other side of the earth - then it's definitely your problem, and your boss should handle it.
And finally, if your boss thinks you're wrong, you're probably in the wrong place.