Refactoring is usually defined as changing code without changing the observable behavior of functionality. This is an important distinction because it is very easy to go overboard and start fixing bugs and changing behavior of the software. When several things start changing it is easy to lose control and the refactoring turns into fixing everything which will take a lot of time.
Do one thing at a time, make a note of the other things that would be useful to do and complete the refactoring before moving on to those.
When refactoring it is useful to have tests to ensure that the software will continue working in the same way as before. Automated tests have obvious benefits but they will also add their own maintenance overhead.
If an automated test for a refactoring is considered not beneficial in the long term it can still be used for testing the refactoring and it can be removed after that.
Large refactoring attempts are very risky. If possible, change one component at a time, keep the software working, have the change reviewed and then move on to the next.
Often there is no time available for large refactorings anyway so it is often best to incorporate small refactoring into daily workflow. Leave the codebase in a bit better condition than what it was when you found it.
Also remember that previous programmers probably had less information about the software than you now have. And remember that people prioritizing tasks rarely have enough competence or information about the code to make wise decisions about the amount of refactoring that needs to be done. The only ones in good position to make good decisions about maintenance are the people doing the maintenance.
Do one thing at a time, make a note of the other things that would be useful to do and complete the refactoring before moving on to those.
When refactoring it is useful to have tests to ensure that the software will continue working in the same way as before. Automated tests have obvious benefits but they will also add their own maintenance overhead.
If an automated test for a refactoring is considered not beneficial in the long term it can still be used for testing the refactoring and it can be removed after that.
Large refactoring attempts are very risky. If possible, change one component at a time, keep the software working, have the change reviewed and then move on to the next.
Often there is no time available for large refactorings anyway so it is often best to incorporate small refactoring into daily workflow. Leave the codebase in a bit better condition than what it was when you found it.
Also remember that previous programmers probably had less information about the software than you now have. And remember that people prioritizing tasks rarely have enough competence or information about the code to make wise decisions about the amount of refactoring that needs to be done. The only ones in good position to make good decisions about maintenance are the people doing the maintenance.
