I recently got an epiphany reading the venerable SICP book. Best abstractions are not about wrapping everything in functions and calling it DRY. You create layers.
If you have 2-3 problems that kinda look similar, you could wrap them up in a function, with some arguments for variation, and pat yourself on the back for DRYing it up. But after some time you get a 4th or a 5th occurrence of the same problem, all slightly different.
Obviously you could create a mess of things by abstracting away what are different problems, but I don’t think “just don’t do abstractions until its really obvious” is a solution, to me it sounds more like giving up. And worse you can end up with piles of code that look kinda similar but with small differences here and there, really hard for new comers to parse and reason about.
What I think is a better approach is to try to come up with abstraction “layers” - smaller pieces of blocks that would make the same problem trivial to solve.
You got your 2-3 pieces of code that look kinda similar. OK do they have smaller parts that its dead obvious that are similar? Abstract away those, now you are left with parts you might be happy to leave as is, don’t need one big function for all of it.
And sure this has pitfalls too, but a good way to test any abstraction is to see how leaky it is. Can I successfully understand and reason about whats going on by just reading the function names / descriptions / types? Does it compose? Yes? Awesome now you have a layer you can build your business logic on. No? Well either change it or get rid of the abstraction until you can come up with a better one.
If you have 2-3 problems that kinda look similar, you could wrap them up in a function, with some arguments for variation, and pat yourself on the back for DRYing it up. But after some time you get a 4th or a 5th occurrence of the same problem, all slightly different.
Obviously you could create a mess of things by abstracting away what are different problems, but I don’t think “just don’t do abstractions until its really obvious” is a solution, to me it sounds more like giving up. And worse you can end up with piles of code that look kinda similar but with small differences here and there, really hard for new comers to parse and reason about.
What I think is a better approach is to try to come up with abstraction “layers” - smaller pieces of blocks that would make the same problem trivial to solve.
You got your 2-3 pieces of code that look kinda similar. OK do they have smaller parts that its dead obvious that are similar? Abstract away those, now you are left with parts you might be happy to leave as is, don’t need one big function for all of it.
And sure this has pitfalls too, but a good way to test any abstraction is to see how leaky it is. Can I successfully understand and reason about whats going on by just reading the function names / descriptions / types? Does it compose? Yes? Awesome now you have a layer you can build your business logic on. No? Well either change it or get rid of the abstraction until you can come up with a better one.