The "don't repeat yourself" principle is well established, but over-aggressive refactorizarions to extract common code are also widely known for creating hard to maintain code due to the introduction of tight coupling between components that should not be coupled. A passing resemblance between code blocks is reason enough to extract them away, even if that ends up breaking Liskov's substitution principle.
To mitigate problems caused by DRY fundamentalisms, the "write everything twice" (WET) principle was coined. WET works by postponing aggressive refactorizarions, the kind that introduces complexity and couples unrelated code just because it bears some resemblance, by creating a rule of thumb where similar code blocks showing up twice in the code should not be refactored, and only code that shows up multiple times should be considered for this task. However, this rule ignores context and nuances, and can dissuade developers from cleaning up code.
So, where do you stand on the topic? How do you deal with duplicate code? Do you follow any specific rule of thumb?
Important/generalized patterns reveal themselves over time. I generally push for people to just write the specific thing they need for the given context and then if the same pattern shows up elsewhere, promote the code to a shared library. It’s really hard to anticipate the correct abstraction right from the start, and it’s easy to include a bunch of “just in case” parameterization that bloats the interface and adds a lot of conceptual overhead.
That being said, with low-leverage/complexity code like html views, repetition isn’t as problematic. Although, I do think that HTML components have matured enough to be the correct unit of abstraction, not CSS classes.
If I find myself repeating more than twice, I just ask "Can this be a function". If yes, I move it there. If not, I just leave it as it is.
Life's too short to spend all day rewriting your code.
I prefer the FP approach where I create smaller functions that I compose together in larger functions or methods wich rarely repeat themselves elsewhere identically. Forcing extractions and merging of such functions often leads to weird code acrobatics.
WET/DRY-ness is like a property of code -- a metric or smell perhaps, but not something to goal towards. That's like asking whether you drive fast or slow and whether we should all drive faster or slower.
The implementations mostly don't matter. The only thing that you need to get right are the interfaces.
I liked this talk on the subject: https://www.deconstructconf.com/2019/dan-abramov-the-wet-codebase
It's a nice explanation of how it's less about code that looks the same or currently performs the same operations, and more about what it means.
I don't think DRY or WET or the "rule of 3" can address the nuances of some abstractions. I think most of the times when I decide to abstract something, it's not because the code looks repetitive, but because I've decomposed the architecture into components with specific responsibilities that work well together.
In other words, I don't abstract from the bottom up, looking at repetitive code. I abstract from the top down, considering what capabilities are required from a system and decomposing the system to deliver those capabilities.
Of course, repetitive code might be a smell, suggesting that there is room for abstraction, but I don't design the abstraction based (entirely) on the existing code.
I agree with WET. We have a tendency to over-complicate things, sometimes you gotta take a breath and ask yourself if the refactor is actually worth it.
There are 2 metrics that need to be considered:
- easy to read
- easy to modify
The first point is by far the most important. Usually DRY win because less code means less to read so less to put in your head. But if the abstraction is too complicated (for example because there are two many parameteres) then it's worth considering drying.
And don't forget the second point, but do not overthing and YAGNI. Sometime a simple comment “don't forget to update method
foobar()” is enough. Don't forget either that you can always rewrite the abstraction when you need to modify something (if the original did not fit your new requirements), but for this to be an easy task, the understanding of the original abstraction must be crystal clear. That's why the first point is so important.It depends on how much regression testing is in place to test that old and refactored code behaviours have the same outputs, and how much budget there is for writing this tests.
For old financial systems for example, the answer is often to repeat the code again, as there's likely to be little tests to confirm existing behaviour and writing tests around very complex business domains is prohibitively expensive.
I just move any duplicate code into a function, no issues yet. (In face, fixing a single bug often ends up fixing multiple problems)
