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

Do we need to avoid duplicate at any cost?

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

复制真的很邪恶吗?我觉得我们可以等待三重(在三个地方重复)发生,然后再将其作为一个函数。但如果我提出这个建议,我就会被视为外星人。我们是否需要不惜一切代价避免重复?

这是管理层、开发人员和 QC 之间的神圣war。

所以要结束这个war,你需要为他们三人制定一个骗子概念。

抽象VS封装,接口VSClass,单例VS静态

你们都需要给自己时间来理解彼此的观点才能使这项工作成功。

例如,如果您正在使用 Scrum,那么您可以进行开发冲刺,然后进行抽象和封装冲刺。

Donald Knuth 引用了您的问题:

The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.

我认为需要复制,以便我们能够理解需要 DRYed 的关键点是什么。

重复代码是应该避免的事情,但在某些(不太常见的)上下文中,抽象可能会导致您编写糟糕的代码,例如,在编写测试规范时,一定程度的重复可能会使您的代码更易于维护。

我想你应该经常问另一个抽象的好处是什么,如果没有快速获胜,你可能会留下一些重复的代码并添加 TODO 注释,这会让你编码更快,更早交付并且只干什么最有价值。

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

  1. The first time you do something, you just do it.
  2. The second time you do something similar, you wince at the duplication, but you do the duplicate thing anyway. (Or if you're like me, you don't wince just yet -- because your DuplicationRefactoringThreshold is 3 or 4.)
  3. The third time you do something similar, you refactor.