Cost Of Refactor Carry

I'm curious about just when refactoring occurs. I get the impression that there are two different things going on here: 1) When a pair doing the simplest thing encounters an obvious refactoring, they do it; the cost is part of their LoadFactor; 2) When a pair has finished an EngineeringTask, they and possibly the Coach or Tester sit down and ask, "Now what can we do with this new work that'll make the whole system simpler?" Maybe only one of these happens; maybe both. Or maybe something else? Maybe sometimes an EngineeringTask is explicitly to do nothing more than RefactorMercilessly? Maybe there's a refactoring phase at the completion of each UserStory or each Iteration? Please clear this up, Xperts. --PeterMerel

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.

CategoryRefactoring
EditText of this page (last edited December 30, 2002)
FindPage by browsing or searching

This page mirrored in WikiPagesAboutRefactoring as of April 29, 2006