3 ms·
> Let's just rewrite stuff and introduce more abstractions when it actually hurts and a refactor is in scope. This is a very good attitude, but I would like to
by majewsky 6y ago
> Let's just rewrite stuff and introduce more abstractions when it actually hurts and a refactor is in scope.
This is a very good attitude, but I would like to tack on a second part to it: Instead of designing your code to be infinitely extensible in all directions, make it easily replaceable instead.
It's impossible to anticipate every future requirement, but certain choices will make it easier to deal with a new requirement as it pops up. One of these things is unit tests. If you have some gnarly business logic with tons of edge cases, you really really want a good test suite because it enables you to add new edge cases with confidence.
- ljm 6y agoI'm a strong proponent of this attitude. The most maintainable code is that you can easily delete. It does require a lot more thought and discipline, because it's not just a case of constructing an epic hierarchy of abstractions, or stubbing/mocking the hell out of your code in the tests to swap things around.
- suzzer99 6y agoCouldn't agree more. A little redundancy early on in a product's lifecycle, when requirements are still in their infancy, can be a very valuable thing. It's much easier to add a layer of abstraction later as requirements became clear, vs. remove an unneeded layer of abstraction (which is often impossible). I've been on too many projects which tried to build the perfect abstraction right out of the box - as if the problem domain fully known.