TABLE OF CONTENTS It would be possible to dedicate a whole book on refactoring code (and indeed people have, an excellent text on refactoring is Fowler (1999)). Here, I will try merely to give some guidance on the when, how and when not of refactoring.
In many ways, refactoring is an obvious idea but one that is hard to put into practise. To some extent this can be due to the old maxim "if it ain't broke, don't fix it." That is, if the code is working at the moment then you don't need to change it. This can be particularly true if management do not see the benefit in refactoring and believe that code that is already written and working should be left as it is and that to do otherwise is a waste of time, effort and money. They presume that you have done it once, so why re-doit. When faced with this approach, many developers will merely opt for the path of least resistance (partly due to management pressure and partly due to their own fear of breaking something that is working). One of the first things that needs to happen for refactoring to be effective is for management to show that they understand the benefits in refactoring (and indeed in the case of XP, its intrinsic part in the development process).
Actually, the old maxim "if it ain't broke, don't fix it" still applies to refactoring within an XP project. That...
