所以干燥代码应该是件好事，对吧？在我从事的其中一个项目中存在一种情况，其中某些模型/实体或多或少是相同的，除了使用它们的上下文之外。也就是说，每个这样的实体都有标题、描述、标签、user_id 等和一些其他属性。因此，他们在各自 Controller 中的 CRUD 操作看起来非常相似。
我的经理争辩说它的代码重复，需要干掉。因此，他提出了 CRUD ruby 模块，当 included 为所有这些实体的 Controller 处理 CRUD 操作时。但最终，Simplicity 受到了损害。代码失去了可读性，因为每个“事物”都被命名为“对象”。调试变得困难，干燥代码的全部意义都丢失了。
这只是一个案例。其中有几个 DRYing up 导致了复杂的、难以调试的代码。所以问题是，我们什么时候停止 DRYing 代码？因为并不是每次你都意识到代码已经失去了简单性(而且代码作者往往从来没有意识到代码的简单性已经丢失)。此外，如果我们必须在简单代码和 DRYed 代码之间做出选择，那么应该选择什么，如果出现只能获得其中之一的情况。
最佳答案
据我所知，如果 DRYing up code 导致失去简单性，那我们就大错特错了。我认为，我们应该 DRYing 重复且具有单一职责的代码。如果代码职责不同和/或无法命名实体的抽象，则我们不重复代码。代码模式可能会重复，但它是一个完全不同的代码，具有自己的责任。如果 DRYing 导致代码模糊，您可能正在尝试 DRY 具有不同职责但具有相似模式的代码，这并不是一个好的做法。 DRYing 应该增强简单性，而不是抑制它。
关于ruby-on-rails - 什么时候停止 DRYing 代码？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1529810/