Author: Martin Fowler · Published: 1999 · Genre: Programming, Software Engineering
Refactoring‘s biggest strength is that it turned vague “code cleanup” into a disciplined technique: a catalogue of small, named, behavior-preserving changes you can apply safely one step at a time. Its biggest weakness is that most of the book is that catalogue, a reference to consult rather than a book to read straight through, and modern IDEs now automate much of its mechanics. Every developer who maintains existing code should read the opening chapters.
The core ideas
Fowler wrote the book with contributions from Kent Beck and others. The 2018 second edition switched the examples from Java to JavaScript.
- A precise definition. Refactoring is a change to the internal structure of software that makes it easier to understand and cheaper to modify without changing its observable behavior. If the behavior changes, it isn’t refactoring. Fowler has long complained about the word being used loosely for any rework.
- Small steps, constant tests. Each step is tiny and you run the tests after every one, so you are never far from working code. Self-testing code is the precondition.
- Two hats. Borrowing a metaphor from Kent Beck, you are either adding functionality or refactoring, never both at once.
- Code smells. A chapter written with Beck lists warning signs such as Duplicated Code, Long Function, Feature Envy (a function more interested in another class’s data than its own), Shotgun Surgery (one change forces edits in many places), Primitive Obsession and Speculative Generality. Comments are often a deodorant covering bad code.
- The catalogue. Each refactoring has a name, motivation, step-by-step mechanics and an example: Extract Function, Inline Function, Rename Variable, Move Function, Introduce Parameter Object, Replace Temp with Query, Replace Conditional with Polymorphism.
What’s great
- The first chapter. A single messy function (a video rental store in the first edition, invoices for a theater company in the second) is refactored step by step into clean code. It’s the best demonstration of the technique anywhere.
- A shared vocabulary. Terms like Extract Function and Feature Envy became industry language, and IDE refactoring menus use many of the same names.
- When to do it. The Rule of Three, which Fowler credits to Don Roberts, is sensible: the first time you just write the code, the second time you wince at the duplication, the third time you refactor. Fowler also argues for refactoring while adding features, fixing bugs and reviewing code, not in separate cleanup projects.
- An economic case. Fowler says you refactor because it makes you faster at the next change, not because clean code is pretty. That framing helps when you have to justify the work to a manager.
What’s weak
The catalogue is long and repetitive. Many entries come in inverse pairs, such as Extract Function and Inline Function, and the numbered mechanics read like a manual. Tools now perform many of these moves in one keystroke, so the lasting value is in the judgment, not the steps.
The book also assumes good test coverage. Real legacy code often has none, and for that situation Michael Feathers’ Working Effectively with Legacy Code (2004) is more useful. Finally, applied too eagerly, the bias toward extracting ever-smaller functions can fragment code into a maze of tiny pieces, the same criticism aimed at Clean Code. Fowler says to inline functions that stop pulling their weight, but readers tend to remember only the extracting.
Who should read it
Any developer working on code that has to live for years. Read the second edition (2018): chapters one to four cover the example, the principles, the smells and testing. Then skim the catalogue and return to it as needed. Teams working mostly in Java may still prefer the first edition’s examples.
Rating: 4.5/5
Image credits — Featured image: cover image via Open Library; cover design © the publisher, shown for review purposes. In-article images: Photo by Compagnons on Unsplash.
