使⽤复制粘贴编程！黄鹤楼诗句
复制粘贴不好
我们讨厌复制粘贴。 为什么？ 因为结果代码⽆法维护。 我收到了质量检查报告的错误，我分析了代码，看了⽇志，调试了，喝了很多咖啡，最后我得到了代码的根本原因。 我修复了该问题，测试了⽤例，发布了新代码以了解第⼆天在相似的⽤例中会出现⼀个⾮常相似的错误。 在这种情况下，另⼀种代码看起来与我前⼀天要修补的代码⾮常相似，⽽我只是开始怀疑我将⾯对并且必须更改同⼀代码的更多副本。
有⽐复制粘贴更糟糕的事情
现在想象⼀下像电影中的短笛。 让我们跳到另⼀个时间。 我收到了质量检查报告的错误，并分析了代码。 我不明⽩。 有很多⼩型接⼝，抽象类，深层次结构。 许多课程与业务没有直接关系。 我向创建代码的开发⼈员寻求帮助，他开始解释。 在两天内，我开始理解他的编码结构思想，以及他如何以严格的⾯向对象的⽅式实现代码，从⽽避免了丝毫的复制/粘贴。 三天后，我到了必须修改⼀⾏的地⽅。 在此之前，我计划先创建失败的单元测试，然后修复代码并重新运⾏单元测试，以确保不再发⽣相同的错误。 因此，我打开了将要修改的单元测试类，但我不知道它是如何⼯作的。 它很复杂，并且扩展了另⼀个使⽤另⼀个类的类。 这次⽐较容易理解，因为我已经了解了创建它的程序员的思维⽅式，但是创建新
测试仍然整天。 我们已经进⼊第四天，之后，错误报告客户纷纷要求修复。
要复制还是不复制...
哪种⽅法更好？ 是否有⼀些复制粘贴并⾯对某些错误会出现在其他区域，或者在代码中具有极其严格但很深⼊的OO设计，从⽽避免了重新出现错误但学习曲线陡峭的问题？
这个问题没有答案，只有⼀个最好的答案。 它们都不是⼀个好的⽅法。 有时，⼀些复制粘贴可能是可以原谅的罪过。 深层的继承结构很难理解。 通常建议不要超过三个级别。 可能还会有⼈争辩说，在上⾯的⽰例中，可以在没有实际复制粘贴的情况下以较少的继承级别创建代码。 （除了以上内容不是实际的，⽽是从多年经验中总结出来的虚构⽰例。）重复的级别可能与OO结构冲突。 当您具有OO结构时，就可以进⾏抽象。 抽象代码很难理解。 当您复制粘贴修改时，修改后的代码将与您复制的代码处于同⼀抽象级别。 可能更容易理解。
杜江出轨>焊工证怎么考复制单元测试代码
疫情什么时候才能彻底结束当涉及单元测试时，我倾向于原谅复制粘贴和冗长的内容，以获得更简单的结构和可读性。 但这是因为单元测试⽐⽂档更多的是⽂档。 当您⽴即查看时，它们必须具有表现⼒。 不需要调查和理解其他地⽅定义的代码结构即可了解测试的⽬的。 我倾向于同意单元测试，即复制⼀个测试，然后包含稍微
修改的代码。 它仍然具有维护⽅⾯的缺点之⼀：如果更改代码，则更改必须传播到所有其他复制代码的地⽅。 但是在这种情况下，如果您忘记传播更改，则会得到测试错误或失败。 这样，您可以将复制粘贴视为⼀个优势：更改代码时，您不得不查看，重构和考虑所有受影响的测试⽤例。
不要复制⽣产代码
在单元测试代码可能使⽣产代码变成噩梦的情况下，这些使缺点变成优点的效果。 如果您有疑问，请不要复制。 不要害怕创建过于陡峭的层次结构。 程序员更容易陷⼊复制粘贴陷阱，⽽不是陷⼊陡峭的层次结构。 除⾮您是⾼级程序员，否则建议您不惜⼀切代价避免在⽣产代码中粘贴粘贴。 如果您是⾼级学⽣，则不需要我的建议：您将避免⾃⼰复制粘贴。
边注
只是⼀个故事： 前⼀段时间，我⽤代码写了⼀些有关复制粘贴的邮件，并创建了⼀个输⼊复制粘贴的错字。⼏分钟后，我得到了答依组词
送男生什么礼物复：“⾯⾷？您指的是意⼤利⾯条代码？”命名预兆。