Learn more about computerscience with this collection
Understanding machine learning models
Improving data analysis and decision-making
How Google uses logic in machine learning
DRY is not a silver bullet
"Don’t repeat yourself" (DRY) is usually good advice, but you have to get the abstractions right. Otherwise they quickly become unmaintainable.
Here's how it usually plays out:
- You write a cool abstraction
- Time passes
- A new requirement appears for which that abstraction is almost perfect
- Programmer B gets tasked to implement it. They feel honor-bound to retain the abstraction, so they alter the code to take a parameter, and then add logic to conditionally do the right thing based on the value of the parameter
Loop these steps a couple of times and you quickly get an unmaintainable mess.
2
43 reads
Wrong abstractions
If you find yourself passing parameters and adding conditional paths through shared code, the abstraction is wrong. It's no longer right for the codebase.
Wrong abstractions are no longer common abstractions; they are series of conditions mixed with vaguely related ideas. This makes them:
- hard to understand,
- easy to break, and
- hard to modify to implement new features.
2
22 reads
Fix wrong abstractions
In the long run, it's better to fix wrong abstractions ASAP than to add more code and make everything more complicated.
Your goal is to remove the abstraction and conditionals, and to reduce each caller to only the code it needs. Here's how:
- Re-introduce duplication by inlining the abstracted code back into every caller
- Within each caller, use the parameters being passed to determine the subset of the inlined code that this caller executes
- Delete the parts that aren't needed for this particular caller
Once done, you can start anew, re-isolating duplication and re-extracting abstractions.
2
17 reads
The right way to abstract
Start by implementing the problem in the concrete, not in the abstract. Don't try to guess what interfaces you will need. Discover them.
Only after implementing the problem in the concrete, go on to decoupling. Ask yourself: "What do I need to decouple to make it better, to allow it to deal with change as the data or business changes?".
Leaving the code in the concrete is also an option. Don't force abstractions when they are not necessary. Prefer duplication over the wrong abstraction because duplication is cheaper to deal with.
2
17 reads
CURATED BY
Alt account of @ocp. I use it to stash ideas about software engineering
More like this
6 ideas
Read & Learn
20x Faster
without
deepstash
with
deepstash
with
deepstash
Access to 200,000+ ideas
—
Access to the mobile app
—
Unlimited idea saving & library
—
—
Unlimited history
—
—
Unlimited listening to ideas
—
—
Downloading & offline access
—
—
Personalized recommendations
—
—
Supercharge your mind with one idea per day
Enter your email and spend 1 minute every day to learn something new.
I agree to receive email updates