Unlike some of the other advocates for refactoring, I don't think refactoring should be done just because I can. There should be concrete reasons for messing with production code other than, "This way looks cooler." A quick cost/benefit analysis should be done. It shouldn't require an accountant to do it, but you should be able to show that your refactorings will provide some sort of tangible benefit, either in terms of significantly improved performance or decreased maintanence costs.

I do, however, have a few rules of thumb where I will refactor nearly every time. If the code is similar enough to other code where I can generalize (or is a cut and paste copy), I refactor into a generic module. If changes in other code will cause changes in the module I'm looking into, I refactor to break the dependency. If a change will make the code harder to test, I refactor to something that can be tested.