2 ms·
> A well designed abstraction could save you weeks (even months!) of time when you most need it. Or it could cost you a lot if your guesses are wrong. It goes
by vinyl7 4y ago
> A well designed abstraction could save you weeks (even months!) of time when you most need it.
Or it could cost you a lot if your guesses are wrong. It goes both ways.
It's better to write code the simplest way to do what it needs to do now, but in a way that can be pulled out into a new system/abstraction later in an easy way. This is generally done by writing data-oriented code (focus on what the data is and how it needs to be transformed) rather than object-oriented code.
- 0xFACEFEED 4y agoThe problem is that everyone's definition of "simple" and "in a way that can be pulled out" is different. And in any case... just about everything you write is an abstraction to some degree; the question is, where is the line? It's not hard to write abstractions defensively. For example you can limit access to your abstraction to a small and strict interface. What you do behind that interface can be the wild west; as long as you can just lop it off later. > It goes both ways. It does, but the word "simple" is often used in a deceptive way. A cacophony of "simple" systems are actually very complex in aggregate. There are many cases (eg: something is your core business) where you'd want to put a lot of thought into an abstraction ahead of time. You'd then want to validate that abstraction's effectiveness and adjust as you go.