4 reasons to change code
Why do we change code?
In his book, Working Effectively with Legacy Code, Michael Feathers offers four reasons:
- Adding a feature
- Fixing a bug
- Improving the design
- Optimizing resource usage
I’ve yet to think of a 5th reason.
So what?
These 4 reasons are the basis for a personal rule when writing code:
Each pull request must address only one of these reasons.
Mixing concerns in a single PR can lead to all sorts of problems:
- It makes the PR much harder to understand and review
- It makes deploying the PR more dangerous (if a bug is found, is it due to the new feature, or the refactoring?)
- It makes reverting the PR dangerous (you can’t revert a broken feature without also reverting useful bug fixes)