Refactoring is a manner of modifying code. The idea of refactoring is that you never rip out a large part of a program and replace it with somehting new. instead, you make baby-step changes, e.g. moving a method to a new class, splitting a single class into two. Not rewriting 5 classes at once. I've heard some people say refactoring only applies to changes which don't modify the behavior of the code (i.e. fucntionality), and I've heard others disagree. In either case, wherever you think refactoring ends and new functionality begins, when you want to do a bug fix, or add new functionality, you look at the code structure, and decide whether the design still makes sense in the context of the new functionality. If it does not, you modify the structure of the code to better support what you want. I guess you could say refactoring is structural modification of code for the purpose for better aligning it with the functional intent. As code lives, and gets extended, usually the original design is not as ideal for the current use as you'd like; the answer is to refactor. A good practice in refactoring, and one heavily proposed by XP, is that after each change, you run regression testing, to insure that the code behaves the same way, and no new bugs were introduced. martin Fowler is considered the expert on this subject, he wrote a book on the topic. Check out http://www.martinfowler.com/ on the book, and on refactoring in general.
I think Mark summed it up pretty nicely. The best short description of refactoring that I have heard is actually the subtitle of Martin Fowler's book: "Improving the design of existing code", because that's what refactoring essentially does. It can completely change the way you develop software, since you don't really need to try to come up with the perfect design at the beginning of the project, knowing that you can always refactor it later. -Mirko
Joined: Jan 21, 2001
Originally posted by john allen: What do you mean by refactoring?
Hi, Of course, now there is talk of "refactoring" patterns! Some of the patterns that have been written over the past few years clearly need to be re-structured! That includes some famous ones, like those in the GoF book *and* it includes some not-so-famous that perhaps need to be completely discarded based on what we have learned! This is an on-going process. Patterns, like software, constantly must change to be useful. This is really one of the fundamental reasons for the publication of the Pattern Almanac (get your free copy this week!). It shows the current state of the patterns literature to make it easier for authors to refactor theirs and others' patterns.
The "new" thing about the refactoring concept is recognizing and naming something that has always been there and trying to define a better approach for doing it. For that we are grateful to Martin Fowler and the other contributors to his book. Linda