Refactoring without pragmatism can be a dangerous practice. Being professional means to understand trade-offs. Although we want to make the whole system better, we may not need to. There is no point in refactoring a piece of code that hasn’t been changed in years. If we don’t need to change it, chances are we should not be refactoring either. Start refactoring what changes more often. The Boy Scout rule should just be applied when we need to make a change or understand one area of the code, not everywhere.
A clean and maintainable code enables developers to go fast and reduces the chances of new bugs. That’s value to the business.
When the code is not well structured, first refactor the code to make it easy to add the feature, then add the feature.
If the code works and doesn’t ever need to change, it’s okay to leave thing the way they are. But if someone does need to work with the code and struggles to follow it, you need to fix this.
First step: ensure that you have a solid test suite for the section of the code you plan to refactor.
Test after every refactoring, however simple. If mistake was made, it’s better to find it early when not a lot was changed.