4 ms·
I think the best way to understand DRY is by thinking about the practical problem it solves: you don't want footguns in the codebase where you could change some
by derefr 2y ago
I think the best way to understand DRY is by thinking about the practical problem it solves: you don't want footguns in the codebase where you could change something in one place, but forget to change the same thing in other places (or forget to change the complementary logic/data in other components.)
The goal of DRY as a refactoring, is first-and-foremost to obviate such developer errors.
And therefore — if you want to be conservative about applying this "best practice" — then you could do that by just never thinking "DRY" until a developer does in fact trip over some particular duplication in your codebase and causes a problem.
- rezonant 2y ago> you don't want footguns in the codebase where you could change something in one place, but forget to change the same thing in other places This. Ironically the example on TFA is vulnerable to this issue. Each of the deadline setting methods has a copy of the validation ensuring that the date is in the future. If it's discovered that we need to ensure deadlines are set no later than the project deadline (since that wouldn't generally make sense), it's awfully easy to only update one and miss the others, especially after code has been added and these implementations are no longer visually near each other. I'm not saying that this means the code must be DRY'ed, but it is a risk from the beginning of the project, so one that needs to be weighed during initial implementation.