A good rule of thumb I use is that once you see the same pattern show up three times, you start to look at how to generalize it so you’re not repeating things. Sometimes you’ll know that it will be repeated and you can address it right away. Even if the generalization seems obvious, though, it may be good to wait.
Another case is large quantities of shared material. If you have two configurations, for example, that share a lot of settings, it might be worth it to write it in such a way as to have one place for it.
The rule of three is nice and pithy, but I think a better rule is to just wait until you see a useful abstraction. This makes DRY less of a tactical rule, and more of a strategic one.
Meaning, I used to see two duplicate pieces of code, and I’d automatically create an abstraction. Now I just repeat the code until the abstraction becomes clear. It might be clear on the second usage, and if so there’s no need to artificially wait for the third.
Sometimes I think the abstraction is obvious the second time I see the pattern, but I’ll still wait for the third use to confirm that I’m really actually going to use it that third time.
To be clear, by the third time it shows up I start to look for the abstraction to see if there is something there. It does not mean I actually make the abstraction.
I think abstracting anything that you can is more general than the simpler and more straightforward case of having one source of truth for business logic. Having two sort implementations is not a huge deal since sorting is pretty universal, but business logic divergence is a much bigger problem.
A good rule of thumb I use is that once you see the same pattern show up three times, you start to look at how to generalize it so you’re not repeating things. Sometimes you’ll know that it will be repeated and you can address it right away. Even if the generalization seems obvious, though, it may be good to wait.
Another case is large quantities of shared material. If you have two configurations, for example, that share a lot of settings, it might be worth it to write it in such a way as to have one place for it.
The rule of three is nice and pithy, but I think a better rule is to just wait until you see a useful abstraction. This makes DRY less of a tactical rule, and more of a strategic one.
Meaning, I used to see two duplicate pieces of code, and I’d automatically create an abstraction. Now I just repeat the code until the abstraction becomes clear. It might be clear on the second usage, and if so there’s no need to artificially wait for the third.
Sometimes I think the abstraction is obvious the second time I see the pattern, but I’ll still wait for the third use to confirm that I’m really actually going to use it that third time.
To be clear, by the third time it shows up I start to look for the abstraction to see if there is something there. It does not mean I actually make the abstraction.
It’s easy to read “three” and infer “if you see three, then DRY” but really what you’re saying is “do not DRY until after you see three”.
I think abstracting anything that you can is more general than the simpler and more straightforward case of having one source of truth for business logic. Having two sort implementations is not a huge deal since sorting is pretty universal, but business logic divergence is a much bigger problem.
Ooh, I like this one a lot. I’m going to remember the seedling analogy.