我的一个同事在我们一起工作的项目中实现了一个新特性，他通过从同一个项目中获取一个包含类似特性实现的文件，创建它的副本重命名所有全局声明并稍微修改执行。所以我们最终得到了两个除了重命名之外几乎相同的大文件。
我试图解释这使我们的项目更难维护，但他不想改变任何东西，说这样对他来说更容易编程，如果“不是”就没有理由修复代码坏了”。
我怎样才能让他相信这样的代码重复是一件坏事？
它与这个问题有关，但我对针对技术人员（另一位程序员）的答案更感兴趣，例如参考像一本书这样的权威资料会很棒。我已经尝试过简单的论点，但没有成功。
问他当他在代码中发现错误时会怎么做。他现在需要修复多少个地方？
您还可以向他展示这个问题的答案（为什么“复制和粘贴”代码很危险？）。
当他想喝咖啡时，让他从咖啡壶里一次喝一口，而不是一整杯。如果他添加了奶油和糖，这将特别有效，而这些奶油和糖必须以极小的部分进行涂抹。这应该说明重复性任务是多么繁琐和累人（比如纠正 20 段代码而不是 1 段）。
然后，向他发送此帖子的链接，以便他可以看到所有其他支持您的人。
这里有两个选项：
他是一个理性的人，根本没有太多的经验。在这种情况下，您可能会合理化您的论点，也许可以通过向他展示您的代码中其他人的代码重复的更清晰示例。您还可以在原始副本中找到一个错误（或者更好，一些错误），现在告诉他他的代码已损坏，他必须修复它。
他是个顽固的混蛋：那你不应该在他身上浪费精力。去找他的老板，让老板处理。有些人就是这样。
虽然第一个选项显然要好得多，但有时您别无选择。如果你最终需要在凌晨 3 点维护他的代码，因为一些重要的客户开始在地球的另一端大喊大叫——那么这绝对是你的问题，你的老板应该处理它。
最后，如果你的老板认为你错了，你很可能来错地方了。
给他一份Refactoring。
改进你的代码版本，以至于他嫉妒得沮丧，然后说 - 如果你刚刚链接到我的代码......
您的同事通过牺牲组织的长期有效性（例如，他的其他同事以及他自己）来优化他的短期有效性。第一个文件所需的任何更改都可能在第二个文件中需要，但没有人会记得......这将导致 2 个查找和修复周期，而不是一个。
你可以在代码上运行一个克隆检测器，然后简单地将结果展示给他的经理。
有关列表的重复代码，请参见Wikipedia。
您可以使用我们的CloneDR检测器查看各种语言的克隆检测示例。它旨在查找具有一致重命名的大代码块，并且可以准确显示发生了什么。
因为当你发现一个 bug 时，你需要在两个地方进行更改。因为当你想添加一个新特性时，你需要在两个地方添加它。
以技术为由向你的老板申诉。如果老板同意您同事的方法/和/或不让他解决问题，那么如果诉诸理性不起作用，您将无能为力。
这不是让你的朋友现在解决这个问题。这是关于发展你的团队。
让他意识到他对团队和项目不公平。如果他仍然不同意，请给他一杯咖啡，让他坐下来喝一口，而你可以拿起他的键盘，真正修复他面前的代码。
他可能会感到羞耻，下次不这样做（大胜利）。我已经使用了 4 次，并且一直有效！
祝你好运。
有很多不复制代码的正当理由，但只是问...您的团队想要维护 100K 行代码（有代码重复）还是 50K 行代码？此时代码重复似乎很少，这就是为什么你的同事没有看到 DRY 概念的重要性，但想象一下，如果他/她在未来 5 年内重复越来越多的代码。谁将维护该代码？你的团队？如果他/她有一天离职了怎么办？你的团队想要维持这种废话吗？:) 如果不是，那么您已经提出了一个非常有说服力的理由来不重复代码，更不用说“更多重复”=“将来更容易出现更多错误”。
告诉他，你永远不知道应用程序在企业中的用途……一个简单的测试应用程序有时会被反复修改，最终被大量使用……我在小公司经常看到这种情况。然后，与其重新开始每一件事，把时间浪费在以前可以解决的事情上，你现在可以简单地做，简短而甜蜜，虽然它可以......
他可能假设它没有坏，也不会坏。此外，完美是善的敌人。我认为他并没有忘记复制/粘贴的危险，他只是对错误可能性的评估与您不同。
也许你可以为他打破它，以表明它是多么容易。如果你不能，也许他是对的。
如果他比您更优秀（或主管），请询问更多解释 - 可能会更多地了解上下文......也许不值得重构代码（也许是一个小项目）。
如果他和你一样，你可以向你的上级报告，提出这个解决方案（这是一个更好的解决方案）。
如果你比他优越，就“要求”他按照你的方式行事……
首先，承认他是对的：现在复制粘贴确实更快了。
然后，说从长远来看问题是成本，成本会增加，因为重复，系统没有像它可能的那样井井有条。他正在引入无序、混乱，而你的无序越多，使用一个系统就越难。现在付出一些努力来更好地组织它（通常）会在长期内得到回报。这就像让您的办公桌或房间井井有条。
这就是 Ivar Jakobson 的软件熵思想