4 ms·
I once worked with a dev who was thoroughly committed to DRY. He'd find a private method somewhere that sort of looked reusable, but also made lots of assumptio
by _ea1k 4y ago
I once worked with a dev who was thoroughly committed to DRY. He'd find a private method somewhere that sort of looked reusable, but also made lots of assumptions about how it was called. Then he'd move it to a public method without documenting all the limitations and try to share it with other code that made different assumptions.
The natural consequence is that both sets of assumptions would have to get baked in somehow.
He'd take similar progressions all over the place to "remove duplication". It wasn't unusual for not only the complexity but also the line count (not including tests) to increase.
If you pointed that out, he'd say, yeah but duplication is always bad!
Needless to say, I don't agree.
- GloriousKoji 4y agoOne of my colleagues is DRY zealot and it drives me nuts. It's always feels like a brain-dead application of a first pass philosophy that doesn't take any greater context or second order effects into account.
- xnx 4y ago"A foolish consistency is the hobgoblin of little minds" and all
- Maultasche 4y agoI heard a good guideline somewhere, that if multiple pieces of code change at the same time for the same reason, it should be combined into one. If the separate pieces of code can change at different times for different reasons (they would likely diverge in different directions the future), it's best to keep them separate places to keep it from being a maintenance nightmare. Excessive DRY as how you described leads to complexity and complexity is bad for code maintainability. Properly applied DRY is supposed to reduce complexity.
- quickthrower2 4y agoThat guideline would make a better tweet than the submission IMO. It is a very good yardstick. Although even if you have to update 2 places together often it might be worth keeping them seperate for various reasons. Such as combining them require major refactor of dependencies.
- jackblemming 4y agoIf combining them would require a major refactor then create a unit test that fails if they diverge or leave a code comment. That gets you the benefits without the tedium.
- _ea1k 4y agoThat sounds like a good rule of thumb to me.
- sharkbird2 4y agoThis sort of thinking about something being 'always bad' or 'always good' is in itself always bad. Not sure if that is a paradox or not, be that as it may, in my experience it is true.