代码之家 › 专栏 › 技术社区 › Samselvaprabu

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

code-cleanup code-duplication coding-style duplicates function

1

Samselvaprabu · 技术社区 · 6 年前

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

复制真的是邪恶的吗?我觉得我们可以等到三倍化(在三个地方复制)发生后再将其作为函数。但如果我这么说的话,我会被视为外星人。我们是否需要不惜任何代价避免重复?

2 回复 | 直到 6 年前

1

2

a--m 6 年前

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

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

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

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

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

当你第一次做某事的时候,你就去做。

第二次你做类似的事情时,你会对复制感到畏缩,但你还是做了复制的事情。 (或者,如果你像我一样,你现在还不会退缩——因为你的 DuplicationRefactoringThreshold 是3或4。)

第三次做类似的事情时,您需要重构。

2

1

Tarek.Eladly 6 年前

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

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

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

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

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