当干的不起作用时，去湿的

这个错误我已经看过很多次了，我自己也犯过。当您第一次阅读枯燥编程概念时，您可能误解了它。

维基百科：Dry代表相同的代码不重复两次。你：嗯，好的，我会把我所有的复制品都换成抽象的。

这看起来是个不错的解决方案，但事实并非如此。你的抽象常常是错误的。

这里有一个小但是：你的抽象几乎是完美的。为什么？新需求只影响您提取到抽象中的旧代码的95%。另外5%不受影响。您决定更改抽象的代码，而不是使用从当前抽象复制的95%的代码来创建新的抽象。例如，您可以添加一个条件语句，例如If..Else，并传递一个参数，这样您的抽象就可以针对不同的决策执行不同的操作。

另一个新的要求到来了。另一个附加参数。另一个新的条件。(循环直到代码变得非常难以理解和维护。)。

代码不再代表单一的、通用的抽象。这就变成了一个充满条件的过程。它很难理解，也很容易打碎。添加新功能非常困难，每一个新功能都会使代码变得更加复杂。

湿(把所有东西都写两次)与干是相反的概念。当您开始开发一个新系统时，您并不知道所有未来的需求。因此，不要仓促地进行抽象。

例如，您正在构建一个Web应用程序，但目前并没有针对所有页面的UI设计。但是你也有很多按钮，它们在每一页上都是相似的。您决定将它们移动到一个名为Button的组件中，并在每个页面上重用它。似乎合乎逻辑。

“嘿，嘿！”新的页面设计来自产品经理。您可以查看它，发现页面底部有一个新的、花哨的按钮。

它看起来像旧的按钮，但它有一个“小东西”。要实现它，您需要重写10%的Button组件，并添加条件语句和新参数。

更改按钮。重写10%的抽象代码(添加逻辑条件以支持新的花哨按钮逻辑)。

我知道你想选择第一个选项。你觉得你能处理好吗。您不会构建错误的抽象。

但可悲的事实是，您会的(除非您是一名经验丰富的程序员，并且知道自己在做什么)。

过一段时间，您就会知道您的按钮将来会是什么样子。然后，您可以分析当前的代码库，在按钮组件中找到重复的代码，并将它们移到良好的抽象中。

如果您发现处理错误的抽象为时已晚，前进的最快方式就是后退。

删除传递给抽象以针对不同决策执行不同操作的未使用参数。

如果您发现自己通过共享代码传递参数和添加条件语句，那么您的抽象是错误的。