4 ms·
Agreed! I'll usually go one step further for early projects and lean towards 3rd time copy, 4th time refactor. Example: So much early code is boilerplate CRUD,
by jumploops 2y ago
Agreed! I'll usually go one step further for early projects and lean towards 3rd time copy, 4th time refactor.
Example: So much early code is boilerplate CRUD, that it's tempting to abstract it. 9 times out of 10, you'll create a quasi-ORM that starts inheriting business logic and quickly grows omni-functions.
Eventually you may actually need this layer, assuming you're system miraculously scales to needing multiple services, datastores, and regions.
However this doesn't just apply to the obvious, and you may find omni-logic that made a feature more simple once and is currently blocking N new features.
Code is cheap, especially today. Complexity necessarily constrains, for better or worse.
- tetha 2y agoHence why I am rather looking if two pieces of code change together, opposed to just looking the same. If I need to introduce the same feature in multiple places in roughly the same way, that's a decent indication code wants to be the same and wants to change together. That's something to consider extracting. Fixing the same bug in several places is a similar, but weaker indication. It's weaker, because a bug might also occur from using a framework or a library wrong and you do that in several places. Fixing the same business logic error in several places could mean to centralize some things.
- sjducb 2y agoIt’s so easy to accidentally write an ORM or a database. I constantly stop and think; is this piece of code secretly a database?