3 ms·
This is true for early high-level decisions. For every-day coding of smallish components in a large project, it matters much less. The more code your design de
by mpartel 5y ago
This is true for early high-level decisions. For every-day coding of smallish components in a large project, it matters much less.
The more code your design decision will affect, the more up-front planning it deserves.
- skohan 5y agoI would argue if “high level design decisions” are getting in the way of coding, this is a sign of over-design or premature abstraction. If you write sufficiently loosely-coupled code, it’s not hard to re-organize later.
- mpartel 5y agoSome examples of high-level decisions: - which web framework? - which database? which ORM? which transaction isolation level by default? - will this game/UI be multiplayer? - what's our testing discipline? You can't loosely couple around questions like these most of the time, at last not without excessive abstraction. For "how do I structure this reasonably isolated 0-1kLOC component", I agree, easy to fix later if needed.
- skohan 5y agoI think there are always ways to minimize coupling. For example if most of the code you write is pure functions operating on values, then swapping out your ORM might be a bit laborious, but it's going to be largely just a matter of typing, not tricky problem solving. And like for example if you want to change web frameworks, that's something you can do incrementally. If you're talking about front-end, just find a way to encapsulate your old code behind a clean interface and start implementing new components in the new framework. If you're talking about back-end, then you can just implement new endpoints in a new language if you want even, and gradually migrate things over when you have to modify them.