Martin Fowler missed out the Most Important Refactoring in his book - delete.
Before applying any of the refactorings in Martin Fowler's catalog, consider one of the delete refactorings. Sometimes, you will find that rather than renaming some badly named method (for example) you can just delete it, which is a much better refactoring.
One of the goals of refactoring is to reduce code entropy - and delete is the best refactoring for this. Less code means: less code to understand, less code to change when you make a change to something it depends on, less code to read through to find what you are looking for, shorter build times, shorter checkout times, shorter search times.
Mike Hill and I have put together a preliminary catalog:
You have code that isn't executed by the deployed system
Examples are: as-yet unrequested functionality, or functionality that is no longer required. Don't delete test or build code related to the deployed system.
You have code that is executed by the deployed system but does not effect the desired functionality of the system.
Examples are: EJBs for systems that don't need them, properties of objects that are set but never read.
You have code that is executed by the deployed system but has not been tested.
If the code hasn't been tested then you don't know what it does, so it is a risk to include it in the deployed system.
You have code that is difficult to maintain.
For example, code that no one understands, code that requires the same changes in multiple places for fixing a bug. Sometimes, you are better deleting it and starting again - but be careful not to jump to this solution too soon, it's often possible to refactor poor quality code into a usable state. (To be fair to Martin Fowler, I think he does mention this one).Posted by ivan at September 20, 2004 12:21 PM