不要试图太过 DRY，而是要把每件事写两遍 (WET)

不要重复自己（DRY）编程，定义

替代方案——“每件事都写两次”（WET）编程

作为开发者，我们经常听到诸如“不要重复自己”之类的陈词滥调。我们接受这样的想法并付诸实践，有时甚至有点过头了。

回顾一下我们为什么要这样做，这很有帮助。所以今天，我们来探讨一下 DRY 编程的另一种理念。

不要重复自己（DRY）编程，定义

DRY 的定义（根据维基百科）为：

每条知识在系统内都必须具有单一、明确、权威的表示。

其中一些可能有点迂腐，但在考虑类似问题时，这可能会有所帮助。让我们分解一下其中的措辞。

每一件

“每部分”是什么意思？变量名不能重复吗？HTML 实体？

好的，好的。所以我们可以<div>毫无问题地重复 's'，我想也不会有人觉得不妥。但这确实引出了一个问题——我们什么时候决定某个东西已经成为“知识片段”？在 React 中，一个很好的例子可能是组件——但这是指“PrimaryButton和”SecondaryButton还是泛型Button类？答案通常被认为是“取决于你的组织选择什么”，但这仍然会在我们选择抽象什么方面留下相当大的模糊性。

知识

这是另一个容易产生歧义的观点——我们该如何定义知识​​？设想一个使用一些原子类和 React 实现的样式化按钮元素。如果高级开发人员需要 10 秒来创建 ，他们可能认为这些知识不值得抽象。但对于不太了解系统的初级开发人员来说，这些知识可能是一个很好的抽象。否则，他们可能需要费力地寻找这些类，提醒自己按钮的工作原理，并弄清楚 的语法onClick。知识是相对的，在定义中使用它会加剧歧义。

更新： Xander 在下面留下了以下评论。我认为那篇文章很好地解释了“知识”的含义。

桑德 • 18年12月19日 • 编辑于12月19日 • 已编辑

只是想把这个留在这里给感兴趣的人。

“DRY 是关于知识的，代码重复不是问题。”
verraes.net/2014/08/dry-is-about-k...

单一、明确、权威的表述

“单一”的表示形式有很多不足之处。从 DevOps 工程师的角度来看，单一表示形式可能是他们需要部署的整个应用程序。对于前端开发人员来说，这可能是一个组件。对于后端开发人员来说，这可能是一个类或 API 端点上的方法。那么，界限在哪里呢？

我们也有“无歧义”这个词——但正如我刚才指出的，这句话的其余部分定义了更多的歧义。“权威性”是有道理的——你的 DRY 代码应该准确定义它的作用，并忠实于该定义。然而，这并不明确地局限于 DRY 代码。

系统

最后，我们来看看“系统”这个词——这又回到了我们刚才讨论的“单个”的说法。什么是“系统”？在 React 中，它可能是一个组件，也可能是一个 Redux 的 action/component/reducer。在容器化软件中，我们讨论的可能是整个 pod，也可能只是一个实例。

说到底，DRY 原则往往会提倡预先优化，这毫无必要，有时甚至会损害你的代码编写能力。有时，修改抽象组件以适应特定用例会更加困难。你要么增加了许多复杂性，要​​么将组件拆分成新的组件——这显然不符合 DRY 原则。你不可能在第一天就了解组件的所有用例。

替代方案——“每件事都写两次”（WET）编程

相反，我建议使用WET编程。对我来说，WET编程的定义是：

你可以问自己两次“我以前不是写过这个吗？”，但绝不能问自己三次。

有了这个定义，重点就不再是过早优化，而是允许你重复编写类似的代码几次。它还将重点转移到更直觉的反应上。它允许你根据正在考虑的具体用例做出决策。如果你正在构建一个 Web 应用程序，你可能希望将按钮抽象成一个组件，因为你将会使用很多按钮。但是，如果有一个页面有一些特殊的样式（也许是定价页面？），那么你不需要太担心抽象出该页面上的组件。事实上，在这个系统下，如果你需要一个与该特殊页面类似的新页面，你只需复制/粘贴并更改所需的代码即可。但是，当这种情况发生第三次时，就该花点时间抽象出可以抽象的部分了。

我还会添加此规定（对于 WET 和 DRY 编程）：

你必须评论你的抽象

每当你将某些内容抽象出来，你都会重新整理你的应用程序结构。如果你不评论并讨论你进行抽象的原因，那么你就是对你团队（以及你未来的自己）的伤害！

你觉得怎么样？这符合你的发展轨迹吗？