违反DRY原则总是坏吗？ [英] Is violation of DRY principle always bad?
问题描述
我一直在讨论 DRY （不要重复自己）原则，也称为 DIE （ / em>），并且有投票，任何简单的代码重复总是一个邪恶。我想听听您对以下几点的意见：
I have been discussing about DRY (Don't Repeat Yourself) principle also known as DIE (Duplication Is Evil) and there are votes, that any simple code repetition is always an evil. I would like to hear your opinion about the following points:
- 不确定的未来。假设我们在两个地方有相同的代码。关键是这两个地方只有偶然的内涵。有一种可能性，因为他们的上下文和语义是不同的，它们将在将来变化。从这些地方抽象并不便宜，如果这些地方之一发生变化，展开抽象将更加昂贵。
- 可读性。有一个复杂的计算涉及到几个变量或步骤。在其他代码的地方有另一个代码，有一些部分是相同的。问题是，如果我们取出共同的部分，计算的可读性将减少，创建抽象将很难给它一个描述性的名称。更糟糕的是，如果某些部分算法会在将来改变，如第1点。
- Uncertain future. Let's say, that we have the same code in two places. The key is, that these two places have only incidental connotation. There is a possibility, that they will vary in the future because their context and semantics are different. Making an abstraction from these places is not cheap and if one of these places change, unwrapping from abstraction will be even more expensive.
- Readability. There is a complex computation that involve several variables or steps. In other place of code there is another one, that have some parts identical. The problem is, that if we take out the common parts, the readability of calculation will decrease and created abstraction will be very hard to give it a descriptive name. Worse, if some part of algorithm will change in the future like in point 1.
上述情况是放弃的理由抽象过程，只是留下重复的代码，有利于未来变化的风险或只是可读性？
Does the above cases are good reason to give up abstraction process and just leave duplicated code in favor of risk of future changes or just readability?
推荐答案
这些是完全有效的原因违反干。我应该增加三分之一：表演。这很少是一个大问题，但它可以有所作为，抽象可能会减慢事情的风险。
Those are entirely valid reasons to violate DRY. I should add a third: performance. It's rarely a big deal, but it can make a difference, and abstraction can risk slowing things down.
实际上，我将添加第四个：浪费时间和潜在的介绍通过更改可能已经正常工作的代码库的两个（或更多）部分来修改新的错误。如果你不需要这些东西，抽出这些东西是值得的，这可能不会在将来节省很多时间？
Actually, I'll add a fourth: wasting time and potentially introducing new bugs by changing two (or more) parts of a codebase that might already be working just fine. Is it worth the cost of figuring out how to abstract these things if you don't have to and it probably won't save any or much time in the future?
通常，重复的代码不是理想的，但肯定有令人信服的理由允许它，可能包括比OP和我自己建议的更多的原因。
Typically, duplicated code is not ideal, but there are certainly compelling reasons to allow it, probably including further reasons than what the OP and myself have suggested.
这篇关于违反DRY原则总是坏吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
