5 ms·
There are lots of relevant programming aphorisms: "Write the simplest thing that could possibly work." "YAGNI." "KISS." You either have a problem you need to so
by l0b0 8y ago
There are lots of relevant programming aphorisms: "Write the simplest thing that could possibly work." "YAGNI." "KISS." You either have a problem you need to solve or not. If not, why do you expect the process to ever finish?
This is one area where TDD really shines. You write a simple failing test and implement something that makes that test pass. If that isn't sufficiently generic you write another test, make both of them pass, and refactor until the solution is as simple as possible while the tests pass. Repeat to get to where you need to go.
- AlexCoventry 8y agoThere needs to be a balance. You should choose an architecture which will accommodate predictable future needs without too much refactoring. A suite of unit tests can't help you much if you need to unmangle a bunch of severe abstraction violations between what you now need to be well-encapsulated components.
- l0b0 8y agoActual red-green-refactor TDD results in the simplest possible code to solve a problem, IME. Over- or under-abstraction tends to be pretty well instantly recognizable when working with a well written test suite, and can then be easily and safely refactored away.
- AlexCoventry 8y agoThe simplest possible code for the current test suite is not always strategic.