人们过于害怕代码重复，过于憧憬可复用可重用的美好，导致对代码重复发起了一场神圣的战争。如今人们提出了不同的意见，在Twitter上引起了一场争论：
“我呼吁结束针对代码重复的神圣战争。我们让年轻的开发人员和工程师相信这是有史以来最糟糕的事情，当时间告诉我们所有人时，绝大多数情况下，复制比依赖更可取。”
“特别是当我们通过抽象仅仅相似但不相同的代码来创建大量复杂性时。”
“我通常的过程是：1。编写代码。2.复制粘贴代码，修改新用途。3.再次复制粘贴代码，修改新用途。4.当他们全部工作时，如果所有三种用途都可以合理地合并。......很多时候，由于使用不同，答案是“不”。”
“如果它们不能干净地合并，那么合并它们可能不是正确的做法 - 用例太不同了。试图合并它们是方形圆孔。”
“保留3份代码并不意味着它们不可重用，这意味着它们无法高效且干净地合并。”
“不重复代码是一个重要的学习课程。但是，一旦你学会了它，下一步就是学会平衡增加的复杂性与必要的重复。”
“如果遵循SOLID，DRY原则，则会很好。不要重复（单一）责任。”
“KISS胜过DRY。”
“依赖性是已知的。重复的代码很快就变成了未知的未知数。我更愿意与前者打交道。”
“我认为这在很大程度上取决于你的块有多大。小块这很好，但对于大型例程，它增加了你复制bug的机会。一旦我进入了一个或多个代码屏幕，我通常会尝试尽可能多地使用它”
“如果考虑微服务而不是类，则更为真实：服务通过“主要依赖”实现简单性并通过“明智的责任”实现价值（在这种服务中是愚蠢的。）”
“对于只有少数开发人员的小项目，这是事实。在更大的项目上（假设> 10个开发者）我宁愿尽可能避免代码重复。”
“一个新的CRUD API，在我的工作中只涉及50-100个 SQL 表，重约77,000 SLOC，因此打印2000-2500页，4-5密集教科书。这种几何爆炸在实践中发生的唯一方式是复制/粘贴，它会妨碍对理解的任何信心。”
“如果您复制的代码不是您自己的代码：请不要忘记检查并尊重版权 ”
“rule-of-three：在有三个工作（独立编码）的案例之前，永远不要创建“抽象层”。它也不是抽象，而是提取共性。”
“实用/有意识的代码重复和无意识的代码重复之间存在巨大差异。了解抽象和外部依赖的实际成本需要经验！”
“概括通常是错误的。”
“艺术家通过复制大师来学习。”
“重复通常会在系统内发出巨大的问题。SOLID不是银弹，它总是取决于实现者。”
“耦合/依赖对于维护者来说往往比在代码中改变一些地方要糟糕得多。”
“开源曾经是治愈良方，然后一些白痴开始分叉”
我的意见是：可复用是一个响尾蛇或美女蛇，很美好，但是导致过度设计，有界的上下文原则大于可复用！
你呢？
京公网安备 11010802041100号