使用复制粘贴编程！

复制粘贴不好

我们讨厌复制粘贴。 为什么？ 因为结果代码无法维护。 我收到了质量检查报告的错误，我分析了代码，看了日志，调试了，喝了很多咖啡，最后我得到了代码的根本原因。 我修复了该问题，测试了用例，发布了新代码以了解第二天在相似的用例中会出现一个非常相似的错误。 在这种情况下，另一种代码看起来与我前一天要修补的代码非常相似，而我只是开始怀疑我将面对并且必须更改同一代码的更多副本。

有比复制粘贴更糟糕的事情

现在想象一下像电影中的短笛。 让我们跳到另一个时间。 我收到了质量检查报告的错误，并分析了代码。 我不明白。 有很多小型接口，抽象类，深层次结构。 许多课程与业务没有直接关系。 我向创建代码的开发人员寻求帮助，他开始解释。 在两天内，我开始理解他的编码结构思想，以及他如何以严格的面向对象的方式实现代码，从而避免了丝毫的复制/粘贴。 三天后，我找到了必须修改一行的地方。 在此之前，我计划先创建失败的单元测试，然后修复代码并重新运行单元测试，以确保不再发生相同的错误。 因此，我打开了将要修改的单元测试类，但我不知道它是如何工作的。 它很复杂，并且扩展了另一个使用另一个类的类。 这次比较容易理解，因为我已经了解了创建它的程序员的思维方式，但是创建新测试仍然整天。 我们已经进入第四天，之后，错误报告客户纷纷要求修复。

要复制还是不复制...

哪种方法更好？ 是否有一些复制粘贴并面对某些错误会出现在其他区域，或者在代码中具有极其严格但很深入的OO设计，从而避免了重新出现错误但学习曲线陡峭的问题？

这个问题没有答案，只有一个最好的答案。 它们都不是一个好的方法。 有时，一些复制粘贴可能是可以原谅的罪过。 深层的继承结构很难理解。 通常建议不要超过三个级别。 可能还会有人争辩说，在上面的示例中，可以在没有实际复制粘贴的情况下以较少的继承级别创建代码。 （除了以上内容不是实际的，而是从多年经验中总结出来的虚构示例。）重复的级别可能与OO结构冲突。 当您具有OO结构时，就可以进行抽象。 抽象代码很难理解。 当您复制粘贴修改时，修改后的代码将与您复制的代码处于同一抽象级别。 可能更容易理解。

复制单元测试代码

当涉及单元测试时，我倾向于原谅复制粘贴和冗长的内容，以获得更简单的结构和可读性。 但这是因为单元测试比文档更多的是文档。 当您立即查看时，它们必须具有表现力。 不需要调查和理解其他地方定义的代码结构即可了解测试的目的。 我倾向于同意单元测试，即复制一个测试，然后包含稍微修改的代码。 它仍然具有维护方面的缺点之一：如果更改代码，则更改必须传播到所有其他复制代码的地方。 但是在这种情况下，如果您忘记传播更改，则会得到测试错误或失败。 这样，您可以将复制粘贴视为一个优势：更改代码时，您不得不查看，重构和考虑所有受影响的测试用例。

不要复制生产代码

在单元测试代码可能使生产代码变成噩梦的情况下，这些使缺点变成优点的效果。 如果您有疑问，请不要复制。 不要害怕创建过于陡峭的层次结构。 程序员更容易陷入复制粘贴陷阱，而不是陷入陡峭的层次结构。 除非您是高级程序员，否则建议您不惜一切代价避免在生产代码中粘贴粘贴。 如果您是高级学生，则不需要我的建议：您将避免自己复制粘贴。

边注

只是一个故事： 前一段时间，我用代码写了一些有关复制粘贴的邮件，并创建了一个输入复制粘贴的错字。 几分钟后，我得到了答复：“面食？ 您指的是意大利面条代码？” 命名预兆。

翻译自: https://www.javacodegeeks.com/2015/01/use-copy-paste-programming.html