我们是否需要不惜一切代价避免重复？

Question

在我们的应用程序框架中，每当代码重复发生时（即使是最轻微的程度），人们立即希望将其删除并作为单独的函数添加。虽然它很好，但是当它在开发的早期阶段完成时，该功能需要以意想不到的方式改变。然后他们添加条件和其他条件使该功能保持。

复制真的很邪恶吗？我觉得我们可以在将它作为一个函数之前等待三次重复（在三个地方重复）。但如果我建议这个，我会被视为外星人。我们是否需要不惜一切代价避免重复？

Answer 1

Donald Knuth引用了一个引用你的问题：

  

真正的问题是程序员花了太多时间在错误的地方和错误的时间担心效率; 过早优化是编程中所有邪恶（或至少大部分）的根源。

我认为需要重复，因此我们能够了解需要干燥的关键点。

重复代码是应该避免的，但是有一些（不太频繁）的上下文，其中抽象可能会导致代码不良，例如在编写测试规范时，某种程度的重复可能会使代码更容易维护。

我想你应该总是问另一个抽象的收益是什么，如果没有快速获胜，你可能会留下一些重复的代码并添加TODO评论，这将使你的代码更快，更早交付和DRY只有最有价值的

Three Strikes And You Refactor描述了类似的方法：

  

  
1. 第一次做某事时，你就是这样做的。
  
2. 第二次你做类似的事情时，你会在复制时畏缩，但无论如何你都会做重复的事情。   （或者如果你像我一样，你还没有因为你的DuplicationRefactoringThreshold是3或4而畏缩。）
  
3. 你第三次做类似的事情，你重构。
  

Answer 2

这是管理层，开发者和QC之间的神圣战争。

因此，要使这场战争结束，你需要为所有这三个人制定一个conman概念。

抽象VS封装，接口VS类，单例VS静态。

你们都需要花时间去了解彼此的观点，以便做到这一点。

例如，如果您正在使用scrum，那么您可以进行sprint进行开发，然后进行sprint以进行抽象和封装。