A software engineering method in Object oriented languages. It allows you to redesign an existing program to improve the quality of the design.

Started life in the Smalltalk community by people like Kent Beck. Martin Fowler has written "the" book on the subject, strangely enough called Refactoring.
ISBN: 0201485672
A software engineering practice which began in (but is not restricted to) dynamically typed object oriented programming circles. Literally, it is the practice of moving functionality from one place to another internally to the code without changing the external interface.

The central drive behind refactoring is making maintenance easier; this happens for three central reasons:

Refactoring is best-known in the Smalltalk and Extreme Programming circles, but is also a characteristic of good FORTH, and can be applied to nearly any other programming paradigm with good results.

A book by Martin Fowler subtitled "Improving the design of existing code". I highly recommend it.

It is laid out clearly and gives many many ways to spot problem areas and many many specific solutions to clean them up. Perhaps more important, it gives you a language and framework for talking about the whys and hows of refactoring. The book includes suggestions on how to deal with management, and how to use unit testing to further improve productivity.

Copyright 1999, with contributions by Kent Beck, John Brant, William Opdyke and Don Roberts with a forward by Erich Gamma. Part of the Addison-Wesley "Booch Jacobson Rumbaugh" object technology series.
ISBN 0-201-48567-2
LOC catalogue number QA76.76.R42F69

Soundbites

In the book, Fowler pulls out a number of his more quotable sayings into an appendix. Some of them are
  • Refactoring (noun): a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing the observable behavior of the software.

  • Refactor (verb): to restructure software by applying a series of refactorings without changing the observable behavior of the software.

  • When you find you have to add a feature to a program, and the program's code is not structured in a convenient way to add the feature, first refactor the program to make it easy to add the feature, then add the feature.

  • Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

  • When you feel the need to write a comment, first try to refactor the code so that any comment becomes superfluous.

  • Make sure all your tests are fully automatic and check their own results.

  • When you get a bug report, start by writing a unit test that exposes the bug.

  • Don't let the fear that testing can't catch all bugs stop you from writing the tests that will catch most bugs.

Bad Smells in Code

Fowler, with Kent Beck, describes opportunities for code improvement as code smells or code that smells bad. This general description is left purposely vague, but describes it quite well, as any experienced coder will tell you. He describes in depth twenty-two particular code smells, and suggests particular refactorings that might help. Then getting into the meat of the book, Fowler describes some 73 refactorings in seven categories.

Composing Methods

Moving Features Between Objects

Organizing Data

Simplifying Conditional Expressions

Making Method Calls Simpler

Dealing with Generalization

Big Refactorings


Note that, more often than not, refactorings come in opposite pairs: Either split something in two, or consolidate two things into one. Either push something down in the object hierarchy or pull something up. In theory, it seems possible to get into a loop, but in reality this isn't a problem.
These lists were taken from the table of contents. I probably wont write up the individual strategies, because I can't think of any way to do so that wouldn't be a blatant copyright violation.
Don't just read the book. Do it.

Log in or register to write something here or to contact authors.