How To Defactor

Name: We have started calling this "Defactor" at work...

Problem: Someone (not you!) has obeyed DontRepeatYourself and EmergentDesign, but the resulting design sucks. (Blame WhatIsRefactoring!)


Result: A design which is at least different, and possibly better, than it was before!
I find this practice useful when writing highly time-sensitive, performance critical code.

Ugh. I'd hate to call that sort of hand optimization of code 'defactoring', even if it does have some similar methodologies. Defactoring solves a problem (backing up a design so you can try again) that cannot readily be solved by other means, whereas the problem you describe is more of a MissingFeatureSmell that can be resolved by a language feature - perhaps PartialEvaluation (even limited PartialEvaluation such as inlining of code) or CompileTimeResolution.

Q: Wouldn't it be easier -- and more reliable -- just to revert from your source control back to the point before the refactoring started?

A: ItDepends. If features have been added while working with a design (before deeming it 'bad' enough to motivate change) then you will need to port these features back into the new branch after reverting. In that case, it would be difficult to call it 'easier' or 'more reliable'. But if you have the foresight to recognize that a particular refactoring is 'bad' immediately after refactoring (i.e. before any non-refactoring action is taken) then you can more readily revert and try again.

The ReFactoring behavior is supposed to mix in, over time, with adding features. They resist a big revert. If you know you had a big refactor session, only, then you can revert it. But refactors should be chronic, not acute!


View edit of October 28, 2008 or FindPage with title or text search