2 ms·
I believe this article isn't much about DRY, but rather abstracting for future use. DRY isn't just doing the inheritance dance footgun. I'll just add that thin
by chucke 6y ago
I believe this article isn't much about DRY, but rather abstracting for future use. DRY isn't just doing the inheritance dance footgun.
I'll just add that thinking about future use is a practice inherited from classical engineering (the one without "software"), where you had to plan for the potential future installment of cabling or pipes, before it becomes prohibitively expensive to tear walls down and start anew. No YAGNI ain't gonna save your 19th century self.
If course, this practice doesn't make as much sense to the fast paced start up world, where time to market is more important, RAM is cheap, and your company's going bankrupt in 6 months.
- dsego 6y agoDRY is hard to do right, esp. for inexperienced coders. They see three lines of code in more than one place and extract it into a single procedure, without knowing if those three lines of code present a useful abstraction or they are just necessary boilerplate. Soon the codebase become a rube goldberg device with stuff piping in and out of these buckets of DRY code and run-time switches to activate or deactivate behaviors. Instead, you want helpers and components and tools to be reused but only when you notice a pattern, not before.