Refactoring: Improving the Design of Existing Code
- By Charles Ashbacher
- July 13, 2001
Refactoring: Improving the Design
of Existing Code
By Martin Fowler et al.
Addison–Wesley, Reading, MA, 1999
412 pp., $39.95 (hardbound), ISBN 0-201-48567-2
There is no doubt in my mind that this is one of the most significant books
of the year, and that will carry over into subsequent years. The reasons for
this are both statistical and qualitative. First, as the title indicates, the
term refactoring is an all-encompassing one used to describe the modification
of existing code. The most cited statistic is that 80% of development work is
now applied to the maintenance of systems. That could be even higher, depending
on precisely how one defines leaving the realm of construction and moving into
the area of repair and improvement. Also, this is simply a well-written book
with clear, valuable examples.
It is the nature of the game that developers are almost always under heavy time pressures to produce a product. The second nature of the game is that there is an operationally infinite number of ways that most significant systems can be constructed, and the third is that without the precise blueprints that make things easier in other areas, software specifications are almost always open to personal or group interpretations. In this environment, it is impossible to get it right or efficient the first time. With that as a given, this set of detailed blueprints for how to clean up the mess is nothing short of a bible for success.
Unlike many books that deal with development from the first flash of coherent neurons in the brain of a visionary, there are few sections that could even remotely be considered as killer changes, which is one of the strongest arguments in favor of purchasing and studying the book. Once the realm of maintenance is entered, there is a natural and sensible reluctance to change. Since most of the refactoring techniques listed here are small, generally local to the code, and "easily" implemented, the fear factor is reduced. Only fragmentary recompilation would be necessary, and the changes can be at least partially tested outside the realm of the complete application. This would make the refactoring process an incremental one with small steps, which has proven to be the most effective way to create software.
While there is a wide range in the level of benefits that can be achieved from these refactorings, they are all worth performing. It may appear paradoxical to make a code change that causes an increase in the runtime CPU cycles, but if it reduces the number of CPU cycles performed in a carbon-based platform, then the change is cost effective. There are many refactorings that do precisely that.
If there is a downside to this, it is that one could become very frustrated in two ways. The first is that it would be easy to see the applications of many of these refactorings in existing code, but time pressures being what they are, it may not be possible to perform them all. In this case, one must apply good judgment. Life and programming being what they are, there are many cases where a decision can be made to do one of two different refactorings that are to some extent opposites. This is always a problem and if forced to find a criticism of this book, that is the one I would choose. There are some cases where the authors could be a bit more explicit in giving some criteria for the choice. Of course, in their defense, if the code works there is always the sensible choice to just leave it alone.
If you are a manager of a maintenance team, then the best thing that you could do would be to purchase this book for all of your team members and budget in a day or two for some intense study. The long-term benefits will be enormous. If you are a member of a maintenance team, then take a copy to your manager and lobby for the former. If that does not work, study it privately and use it wisely. The knowledge here could make you a star in the increasingly valuable realm of program maintenance.