Ask HN: What is your philosophy when creating abstractions?
4 comments
Count the number of clients that will be ("will" not "could!") taking advantage of the abstraction. Is that number not greater than 3? Then the abstraction is useless and shouldn't be written.
Always KISS. Abstractions should be done in case of Rule of 3 (if you're going to write something 3 times, create a layer of abstraction).
Just don't think too much on abstraction. I've worked on codebases that were designed with abstraction as its first thought, and saw scaling issues (major ones) over time. The key to sustainable codebases is to always KISS. You might feel goosebumps watching your abstract code but sadly, your team might not and the effort it might take to explain the same or the time it would take them to understsnd what you meant does not collectively profit the overall environment of the project as a whole.
Just don't think too much on abstraction. I've worked on codebases that were designed with abstraction as its first thought, and saw scaling issues (major ones) over time. The key to sustainable codebases is to always KISS. You might feel goosebumps watching your abstract code but sadly, your team might not and the effort it might take to explain the same or the time it would take them to understsnd what you meant does not collectively profit the overall environment of the project as a whole.
Having been in the industry I've seen people talk about abstraction in different forms, and displaying different sets of priorities for different properties of abstraction.
I was looking to find a list of things that people consider very valuable when building their own abstractions (or when evaluating which libraries to use in their projects), and what things they think make the codebase worse.