Probably the biggest reason not to mix refactorings with behavior changes is that it makes it too easy to make a mistake. By Jason Swett.
When you look at the diff between the before and after versions of a piece of code, it’s not always obvious what the implications of that change are going to be. The less obvious the implications are, the more opportunity there is for a bug to slip through.
When you mix refactoring with behavior changes, it’s hard or impossible for a reviewer to tell which is which. It makes a discussion about a code change harder because now the conversation is about two things, not just one thing. This makes for a potentially slow and painful PR review process.
How to approach refactorings instead:
- Set aside my current feature branch
- Create a new branch off of master on which to perform my refactoring
- Merge my refactoring branch to master (and preferably deploy master to production as well)
- Merge or rebase master into my feature branch
- Resume work on my feature branch
If developer deploys a behavior change that was mixed with a refactoring, and then discovers that the deployment introduced a bug, she/he won’t know whether it was the refactoring or the behavior change that was responsible because the two were mixed together. Good read!
[Read More]