3 ms·
This feels incredibly broken to me. The 'how' should not change often, because it enforces rapid change on anything which depends upon it. Any system inevitabl
by desc 8y ago
This feels incredibly broken to me. The 'how' should not change often, because it enforces rapid change on anything which depends upon it.
Any system inevitably acquires dependencies. Maybe it's fine to break those dependencies if you're building some public website where you can always have the latest version of the code running, but if you've got customers who depend on having a stable build which was initially branched three years ago and you still need to build, run and test that, you damn well better have a consistent and stable mechanism for dealing with that codebase which spans multiple years. Your ops and QA people will hate you otherwise.
Our own approach has been to pull out the coarse-grained operations and have an 'environment' script which examines the version it's working with in order to spit out relevant details. The 'porcelain' scripts are never allowed to change their API in any breaking fashion, and their behaviour is adapted based on the environment's output.
- rhizome 8y agoDDD: Documentation-driven development. With apologies to Fred Brooks, write documentation first, then write tests for the functionality and syntax described in the documentation, then the code. I would speculate that doing straight docs instead of something like Cucumber would be more productive.