History.

In the past refactoring was avoided in development processes. One example of this is that CVS (created in 1984) does not version the moving or renaming of files and directories.

Although refactoring code has been done informally for years, William Griswold's 1991 Ph.D. dissertation is one of the first major academic works on refactoring functional and procedural programs, followed by William Opdyke's 1992 dissertation on the refactoring of object-oriented programs, although all the theory and machinery have long been available as program transformation systems. All of these resources provide a catalog of common methods for refactoring; a refactoring method has a description of how to apply the method and indicators for when you should (or should not) apply the method.

Martin Fowler's book Refactoring: Improving the Design of Existing Code is the canonical reference.

The first known use of the term "refactoring" in the published literature was in a September, 1990 article by William F. Opdyke and Ralph E. Johnson. Griswold's Ph.D. thesis, Opdyke's Ph.D. thesis, published in 1992, also used this term.

The term "factoring" has been used in the Forth community since at least the early 1980s. Chapter Six of Leo Brodie's book Thinking Forth (1984) is dedicated to the subject.

In extreme programming, the Extract Method refactoring technique has essentially the same meaning as factoring in Forth; to break down a "word" (or function) into smaller, more easily maintained functions.

Refactorings can also be reconstructed to produce concise descriptions of complex software changes recorded in software repositories like CVS or SVN.

Example.

An employee built a prototype of forum manager. It had evolved over months, employee rewrote it to be better designed and fast. This code was beautiful. Well, as more features were added it got spoiled, but it was left. Then the team realized, that it was "taking forever" at startup, because it loaded all forum messages up front. It was finally redesigned to load last 3 months messages and do others dynamically. Actually the team knew that the forum would eventually have this "popularity" problem and it was hanging over the team all the time.

Why Not Enough Refactoring Happens?

1. Refactoring is difficult work.

2. Refactoring is different. How can you convince your management—or yourself, for that matter—to take some time to refactor when there are so many important things that need to be done?

3. Refactoring is politically tricky work. Refactoring doesn't often sit well with management.

4. People do not know what well-written code looks like.

5. Refactoring is unnecessary.

6. Incomplete Regression Tests. Refactoring is too risky without Regression Tests that provide adequate functional and code coverage.

Automated code refactoring.

Many software editors and IDEs have automated refactoring support. Here is a list of a few of these editors, or so-called refactoring browsers.

Conclusion.

So, practically, refactoring means making code clearer and cleaner and simpler and elegant. Improve code structure and design, because code became more maintainable, easier to understand, easier to modify, easier to add new features. When not to refactor? Sometimes you should throw things out and start again. Sometimes you are too close to a deadline.