4 ms·

I consider maintainability and readability related, but two different things. I'd expect maintainable code to be readable. However, I've encountered code bases

I consider maintainability and readability related, but two different things. I'd expect maintainable code to be readable. However, I've encountered code bases that were easy to read, but hard to maintain. I mean that the code was hard to change after new requirements came up. So when writing some code, a programmer needs to have some good understanding on how the business requirements might evolve, and design the code with that in mind, so the next programmer can not only easily read the code, but also change it in face of new requirements.

hakunin 5y ago
The problem is that predicting how a business might evolve is pretty much impossible. It might make more sense to architect for ease of change in general rather than ease of change into a specific direction. To do that (aside from the advice in the article), I like to imagine a scale where static/hardcoded/build-time architecture is on the left end, and dynamic runtime-manageable architecture on the right. To avoid over-engineering, the trick is to always lean as much as possible towards the left side of the scale. Only introduce runtime complexity when absolutely needed.