我们是否需要不惜任何代价避免重复?

Donald Knuth的一句话指出了你的问题:

真正的问题是,程序员花了太多时间在错误的地方和错误的时间担心效率; 过早优化是万恶之源 (或至少大部分)在编程中。

我认为需要重复,以便我们能够理解哪些关键点需要干燥。

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

我想你应该总是问另一个抽象的好处是什么,如果没有快速的成功,你可能会留下一些重复的代码并添加TODO注释,这将使你更快地编写代码,更早地交付,只干最有价值的东西。

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

1. 当你第一次做某事的时候,你就去做。
2. 第二次你做类似的事情时,你会对复制感到畏缩,但你还是做了复制的事情。 (或者,如果你像我一样,你现在还不会退缩——因为你的 DuplicationRefactoringThreshold 是3或4。)
3. 第三次做类似的事情时,您需要重构。

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

因此,要结束这场战争,你需要为这三个国家制定一个骗子的概念。

抽象与封装、接口与类、单例与静态。

你们都需要给自己时间去理解对方的观点,才能让这一切顺利进行。

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