我的一个同事在我们共同开发的项目中实现了一个新功能，他是通过拿取一个包含类似功能实现的文件，创建它的拷贝并将所有全局变量重新命名，稍微修改一下实现来完成的。于是我们就得到了两个几乎完全相同但命名不同的大文件。
我试着解释这样做会使我们的项目更难维护，但他不想改变任何东西，说这种编程方式更容易，而且如果代码没有问题，就没有理由去修复它。
我该如何说服他这样的代码重复是不好的？
这与这个问题有关，但我更感兴趣的是针对技术人员（另一个程序员）的答案，例如引用权威来源如书籍等。 我已经尝试过简单的论点，但没有成功。
当他想要咖啡时，让他一口一口地从咖啡壶里喝而不是一次倒满整杯。如果他加奶油和糖，这种方法尤其有效，因为必须分配出微小的份量。这说明重复性任务非常繁琐和令人疲劳（就像更正20个代码片段而不是一个）。
然后，向他发送此帖子的链接，以便他可以看到其他支持你的人。
这里有两个选择：
他是一个理性的人，只是经验不够丰富。在这种情况下，你可以通过展示另一段代码中更清晰的重复例子来让他理解你的观点。你还可以找出原始副本中的错误(最好是几个错误)，告诉他现在他的代码已经有问题了，必须修复它。
他很固执：那么你不应该在他身上浪费精力。去找他的老板，让老板来处理。有些人就是这样。
虽然第一种选择显然更好，但有时你没有选择权。如果最终需要在凌晨3点来维护他的代码，因为某个重要客户在地球的另一端开始大声喊叫 - 那么这肯定是你的问题，你的老板应该处理它。
最后，如果你的老板认为你错了，那么你可能不在正确的位置。
让你的代码版本变得更好，让他因嫉妒而沮丧，然后说 - 如果你只是链接到我的代码...
因为当你发现一个bug时，你需要在两个地方进行修改。因为当你想要添加一个新功能时，你需要在两个地方添加。
不重复代码有很多合理的原因，但是请问...你的团队想要维护100K行（存在代码重复）还是50K行的代码？现在代码重复可能看起来很少，这就是为什么你的同事没有意识到DRY概念的重要性，但是想象一下如果他/她在未来5年里重复了越来越多的代码。谁来维护那些代码？你的团队吗？如果他/她有一天离职了呢？你的团队想要维护这个垃圾代码吗？ :) 如果不想，那么你已经很有说服力地证明了不重复代码的重要性，更不用说“更多的重复”=“未来更容易出现更多的错误”。
从技术角度向你的老板提出申诉。如果老板同意你同事的方法和/或不让他修复它，那么如果上诉理由不起作用，你就没有太多可以做的了。
