！do Action({ option:' repeat ' })person . extend(constructor(){ this . me = true；这个。_ super()；})
！do Action({ option:' repeat ' })person . extend(constructor(){ this . me = true；这个。_ super()；})
或者为什么我总是故意重复我自己。
我最近和一个开发人员合作了一个项目，他对执行 DRY 原则持有非常教条的观点(不要重复自己)。我个人认为完美干燥的代码是脆弱的，难以理解，难以维护。我当然不是第一个提出这个建议的人，但是在很多情况下我更喜欢重复而不是抽象。
相互矛盾的原则
DRY 在什么程度上有助于创建好的架构模式？首先，我认为重要的是要考虑到使用术语“架构模式”表示一定程度的重复。图案不错！如果所有的代码都是独一无二的，那么所有的代码都必须自己学习和理解。相反，如果代码遵循非常相似的模式，在一个地方学习它，会导致理解所有其他情况。将代码抽象成一个模式只使用一次是不太有用的。在这一点上，它不再是一个模式。
理解枯燥的警告
一个干燥的狂热者将会创造出需要大量理解才能知道那个函数或职业能做什么的函数或职业。这是因为为了使用一个特定的逻辑模式，一个函数或类必须考虑它的所有不同的用例。随着时间的推移，选项和争论会越来越多，责任和复杂性也会增加。
对干的更广泛的看法
因此，我认为为了使 DRY 原则有用，它必须被更广泛地考虑。虽然我认为抽象声音模式和可理解的代码是对 DRY 的拙劣使用，但我认为架构代码使业务逻辑只出现在一个地方是很重要的。如果你的产品的行为发生了变化，你希望能够在一个单独的位置处理这个行为，而不是在应用程序中你能记住的所有地方。这意味着，如果你经常修改数据，以一种特殊的方式显示，确保你在一个地方做，但应用 DRY 到业务逻辑本身，而不是如何业务逻辑被修改。
例如，你可能会发现，在你的应用程序的不同地方，你总是以一种特定的方式过滤产品列表。最好确保这是在代码中的一个地方完成的。然而，如果你也发现你在以类似的方式过滤你的用户，那么做一个通用的过滤器来处理产品和用户可能不是你最感兴趣的，因为当产品或用户的用例改变时，你的干燥就成了一个问题。更不用说，一旦你在同一个通用过滤器解决方案中添加了五个其他实体，对过滤器的更改可能会对整个应用程序产生广泛的、可能难以完全理解的影响，而不是对单个实体产生影响。
需要时应用
最后，我认为 DRY 要考虑的一个更重要的方面是，只有当你发现自己已经在重复或者将要重复的时候，你才应该使用它。花费时间和精力对代码进行预干燥是低效的，并且注定要进行重构。用完美的代码来猜测未来的用例比用易于修改的代码来处理它们要困难得多。如果说我在多年的发展中学到了什么，那就是我错了很多，为此做计划比提高我理解未来的能力更容易。
简单来说:不要干到重复自己。又名:DDRYUYRY。