Tried-and-true refactoring rules:
- Find the smallest change that could possibly work, and check it in. “If I make this change, it will change nothing else.”
- Revert early, and revert often. If you lose a half-day of work because the refactoring change is too large, that’s okay. Better to start over than to cost the rest of the team precious time struggling with a broken build.
- Do not write new code while refactoring.
- Always use cut-and-paste, never copy-and-paste.
- Just because the unit tests pass, doesn’t mean that the product still works after your refactor. You may need to add new unit tests before you refactor. And you may need to do some acceptance-testing for things that aren’t unit-testable.
General Advice:
- Don’t checkin changes to the version control system just before you go home. Wait for the next day.
Types of Refactoring:
- Refer to Martin Fowler’s “Refactoring” book
- Refer to Fowler’s website: http://www.refactoring.com/ and his catalog of refactorings