3 ms·
I use the rule of threes to kill off any premature abstractions. ie. Don’t think you need to make this generic if you have one or two different variants of it.
by coffeebeqn 4y ago
I use the rule of threes to kill off any premature abstractions. ie. Don’t think you need to make this generic if you have one or two different variants of it. Most often it’s one- so it’s very easy to see that you’re just solving imaginary problems at this point.
Each abstraction has a mental cost for reading and understanding the code so I try to be sparing. Too many code bases in my youth were a nightmare to navigate because I could never find any actual concrete code.
- fullstackchris 4y agoAlso don't forget that code (including the complexity you want to add to it) will probably have only something like an aggragate ~1/3 chance of still being used in a production scenario 5 years or so away anyway (for any number of reason, product change, feature removal, company bought / sold, the list goes on and on...) of course these numbers are anedotal but the point is it can be detrimental to think your code will run as is for the next million years, especially after the first draft
- DrJokepu 4y agoThat being said, sometimes a good abstraction can really simplify a complex problem by dividing it up to a set of smaller sub-problems. In such cases, the abstraction is worth it even if there is no reuse. As always, rules like this have to be interpreted in a context.
- coffeebeqn 4y agoIt’s certainly a rule of thumb, I also prefer to break things down but I try to use functions as the basic units as they’re the easiest to keep in your head when it’s clear what they do