good habit when you do feature add/change or refactoring
It is crucial to maintain a clear distinction between refactoring and making changes to a module, feature, or behavior in software development.
Refactoring refers to making changes to the codebase without affecting the external behavior of the software.
In contrast, making changes to a module, feature, or behavior involves altering the external behavior of the software, which often requires additional testing and debugging.
By following the golden rule of not mixing refactoring with changes to a module/feature/behavior, developers can ensure that they are making changes to the codebase in a controlled and predictable manner. This approach results in high-quality code that is more maintainable and easier to debug.
In my personal experience, following this rule has helped me produce software that meets the expectations of stakeholders.
It has also helped me gain their trust as they know that any changes made to the software are carefully considered and executed with minimal risks of introducing new bugs or regressions
Below are some of the points I have highlighted when we try to mix change and refactoring together
Adds Risk
Avoid mixing refactorings with behavior changes as it can lead to mistakes.
It’s difficult to understand the implications of changes just by looking at the difference between the before and after versions.
This increases the chances of bugs slipping through, especially when mixing behavior changes with refactorings.
It also means deploying bigger deltas, increasing the risk of introducing bugs.
If the change deltas are smaller, I override the above rule based on contextual judgment.
Bug attribution becomes harder, post-production deploy
ining a behavior change with a refactoring can make it hard to determine which caused a bug.
Rolling back both changes may be necessary, even if only one caused the issue. Deploying changes separately makes it easier to attribute the bug and avoid rolling back both changes.
Affect pull request review
Mixing refactoring with behavior changes can confuse reviewers, causing the PR review process to be slow and hard.