不要太执着DRY编程，试试WET编程吧

作为开发人员，我们经常听到一些诸如“不要重复你自己”的陈词滥调。我们按照这种思想去编码，并运行代码，有时候结果和我们预想的很不一样。

回头思考并评估一下我们为什么做这些事情是很有帮助的。所以今天，让我们来看看可以代替DRY编程的另一种编程思想。

不要重复你自己(DRY)编程思想的定义

根据维基百科，DRY的定义是:

在一个系统中，每一个知识都必须有一个单一的、明确的、权威的表示。

可能这听起来有点迂腐，但在考虑诸如编程思想之类的事情时可能会很有帮助。我们来分解一下这句话的措辞。

每一个

什么是“每一个”?我们不能重复一个变量名吗?或者一个HTML实体?

好吧,好吧。所以我们可以重复

，这没有什么问题，我认为没有人会反驳。但这确实带来了一个问题——我们什么时候决定某些东西已经变成了“每一个知识”?在React中，一个很好的例子可能是组件——但它是PrimaryButton和SecondaryButton，还是一个通用的Button类?答案通常是“你的团队选择什么”，但是这仍然会让我们对要选择抽象的内容模棱两可。

知识

这是另一个模棱两可的观点——我们如何定义知识?在使用一些原子类和React的时候考虑样式化的按钮元素。如果高级开发人员需要10秒钟来创建，那么他们可能认为这些知识不值得抽象。但是对于一个不太了解系统的初级开发人员来说，这些知识可能是一个很好的抽象。否则，他们可能不得不寻找一些类，提醒别人按钮是如何工作的，并想出一个onClick事件的语法。知识是相对的，在定义中使用它会增加歧义。

地址：http://verraes.net/2014/08/dry-is-about-knowledge/

单一的，明确的，权威的表示（代表）

“单一”的表示方式会带来很多的要求。从一个开发工程师的角度来看，单一表示可能是他们需要部署的整个应用程序。对于前端开发，这可能是一个组件。对于后端开发，可能是一个类的方法或API接入点。这个区分界线从哪里来呢？

我们也有“无歧义”这个词——但正如我刚刚指出的，这句话的其余部分定义了更多的歧义。“权威”是有意义的——你的DRY代码应该准确定义它所做的事情，并要忠实于该定义。然而，这并不仅仅限于DRY代码。

系统

最后，我们来看“系统”这个词——这又回到了我们前一秒钟讨论的“单一”的描述。什么是一个“系统”?在React中，它可能是一个组件或一个Redux操作/组件/还原器。在容器化的软件中，我们可以讨论整个pod，也可以只讨论一个实例。

在一天结束时，DRY 经常会提升预优化，这是不必要的，有时还会损害你的编码能力。有时，修改抽象组件以适应特定用场景会变得更加困难。你增加了很多的复杂性，或者你把这个组件分解成一些新的东西——这并不是特别DRY的。你不可能一开始就知道你的组件的每个用例。

一个替代方法——将所有东西都写两次(WET)编程

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

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

有了这个定义，焦点就不再是提前优化，而是允许你重复几次相似的代码。它还将焦点转移到更直觉的反应上。它允许你根据你正在查看的准确用例做出决策。如果你正在构建一个web应用程序，你可能希望将按钮抽象为组件，因为你将会使用很多按钮。但是，如果有一个具有一些特殊样式的页面(可能是定价页面?)，那么你就不需要过多地担心提取该页面上的组件。事实上，在这个系统下，如果你需要一个跟那个特殊页面类似的新页面，你只需要复制/粘贴并更改所需的代码。然而，当第三次出现这种情况时，就是时候花点时间抽象出可以抽象的部分了。

我还要补充这一规定(对WET和DRY编程):

你必须对你的抽象进行注释。

每当你抽象出某些内容时，你就是在重新调整你的应用程序结构。如果你没有通过备注来说明你进行抽象的原因，那你就是在伤害你的团队(和未来的自己!)

你觉得呢?这跟你的未来发展有关系吗?

英文原文：https://dev.to/wuz/stop-trying-to-be-so-dry-instead-write-everything-twice-wet-5g33

译者：野生大熊猫