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

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

---

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

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

所以为了结束这场战争，你需要为他们三个都制定一个骗子的概念

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

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

---

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

Donald Knuth引用了一段话，指出了您的问题：

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

我认为需要复制，以便我们能够了解哪些关键点需要干燥

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

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

类似的方法如下所述：

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

当你第二次做类似的事情时，你会因为重复而畏缩，但你还是做了重复的事情。 （或者如果你像我一样，你还不会退缩——因为你的身高是3或4岁。）

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

---

视情况而定。干的（不要重复你自己）是一个原则，湿的（每件事都写两遍）是另一个原则。其思想是，如果您使用泛型代码两次以上，那么编写泛型代码的开销是合理的。我认为，真相介于两者之间。