Thanks for asking. All of the above can occur. New code should be refactored before release to remove any redundancies with what has gone before. Sometimes we see things that we didn't notice before and fix them on the fly. We have gone so far as to schedule a refactoring iteration, but this was a recovery from not having been vigilant enough in past iterations. Not recommended. Once in a while, we have seen something big and scheduled it as an EngineeringTask. Eternal vigilance, basically, and good habits to keep the workspace clean. Wish I could do as well with my desk. --RonJeffries
The price of liberty, after all. Makes plenty of sense, but I wonder how all this refactoring affects your test/build/release schedule. Do RefactorCollision(s) ever occur? If so, how badly do they screw you up? --p
In ExtremeProgrammingCodeReviews, RonJeffries says, ExtremeProgramming projects do not require explicit code reviews. Drop them from your methodology. But the above recommendation that new code should be refactored before release to remove any redundancies with what has gone before smells like code review advocacy (admittedly within an XP-pairing frame). -- TomRossen
I recommend the following approach. Refactor before adding a new feature or making a correction and refactor again afterwards. Avoid refactoring for refactoring's sake; only refactor code when driven to make a change. This advice does not limit the scope of the refactoring only requires that it be driven. You don't want to incur any risk without providing some benefit.
Refactor for refactor's sake. Don't enforce RFRS.
See also RefactorLowHangingFruit, DecompressionDebt.
This page mirrored in WikiPagesAboutRefactoring as of July 17, 2004