Page 2 of 2

Posted: Mon Jan 15, 2007 2:07 pm
by Christopher
Hockey wrote:Refactoring without affecting the rest of the system (although ideal) is not always practical. I've always seen refactoring as making a design better overall - as a more cost effective approach to overhauling a codebase.
From the first paragraph at http://www.refactoring.com
refactoring.com wrote:Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. Its heart is a series of small behavior preserving transformations. Each transformation (called a 'refactoring') does little, but a sequence of transformations can produce a significant restructuring. Since each refactoring is small, it's less likely to go wrong. The system is also kept fully working after each small refactoring, reducing the chances that a system can get seriously broken during the restructuring.

Posted: Mon Jan 15, 2007 4:12 pm
by alex.barylski
What are you trying to prove or accomplish other than take this right off course?

Posted: Mon Jan 15, 2007 4:27 pm
by Christopher
Hockey wrote:What are you trying to prove or accomplish other than take this right off course?
This thread is about refactoring and you stated an erroneous definition of the term. As this is a public board I linked to a definitive definition so those unfamiliar with refactoring could have accurate information on the subject. You have said you want to "take baby steps" and not effect the rest of the implementation. There is a wealth of information on doing just that -- it's called Refactoring.