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.
LOC catalogue number QA76.76.R42F69
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.
Moving Features Between Objects
Simplifying Conditional Expressions
Making Method Calls Simpler
Dealing with Generalization
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