Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence when you refactor you are improving the design of the code after it has been written.
"Improving the design after it has been written." That's an odd turn of phrase. In our current understanding of software development we believe that we design and then we code. A good design comes first, and the coding comes second. Over time the code will be modified, and the integrity of the system, its structure according to that design, gradually fades. The code slowly sinks from engineering to hacking.
Refactoring is the opposite of this practice. With refactoring you can take a bad design, chaos even, and rework it into well-designed code. Each step is simple, even simplistic. You move a field from one class to another, pull some code out of a method to make into its own method, and push some code up or down a hierarchy. Yet the cumulative effect of these small changes can radically improve the design. It is the exact reverse of the normal notion of software decay.
With refactoring you find the balance of work changes. You find that design, rather than occurring all up front, occurs continuously during development. You learn from building the system how to improve the design. The resulting interaction leads to a program with a design that stays good as development continues
Martin Fowler
"Refactoring: Improving the Design of Existing Code,"
Addison-Wesley, 1999, p. xvi
In some ways, refactoring a large software artefact resembles the
normalization of a large data artefact. Just as normalization is
supposed to preserve the underlying representational meaning of data
while improving the data structure, so refactoring is supposed to
preserve the (functional) behaviour of an artefact while improving its
structure. Some theoretical work has been going on to prove that
certain precisely defined refactorings are "safe" in this sense, and
tools are being built that implement this notion of safety. Complex
refactorings can be decomposed into a series of safe steps. Of course,
this doesnt mean that you dont have to test the refactored software
but it provides an additional level of reassurance, particularly for
safety-critical or business-critical software.
From Fowler, Chapter 1. This is a step-by-step refactoring of a small program.
Original Movie Rental program
Refactoring: a change made to the internal structure of software to make it easire to understand and cheasper to modify without changing its observable behavior.
Refactoring is no silver bullet but it is a pair of silver pliers to help keep a good grip on your code.