Refactoring
Now you can dramatically improve the design, performance, and manageability of object-oriented code without altering its interfaces or behavior. Refactoring shows
you exactly how to spot the best opportunities for refactoring and exactly how to do it-step by step. Through more than forty detailed case studies, you'll learn powerful - and surprisingly simple - ways to redesign code that is already in production.
You'll learn scores of specific techniques, including when to move fields between classes, when to move code up or down its hierarchy, and when to divide a single method into two. Through intuition and trial and error, master programmers have spent years evolving these techniques; this book brings them all together into a comprehensive guide that any experienced developer can use.
Review By: Brian Marick
03/10/2005Software maintenance is scary. When I worked on a particular version of the Unix kernel, one of the developers called it the "Winchester Mystery Kernel," by analogy to a nineteenth-century house in Silicon Valley that’s famous for inexplicable features such as stairs that go up to the ceiling but not through it. In contrast to the Winchester Mystery House, software systems don’t get incomprehensible on purpose. Rather, they succumb to entropy one change at a time, each change making the next a little harder and a little less safe, until eventually nothing can affordably be done.
Refactoring is about fighting entropy when a new feature has to be added to code that wasn’t designed to support it. A programmer who refactors carefully and methodically transforms the original program into one that behaves in exactly the same way, but now has a structure that makes adding the new feature easy and safe. Then, adding that new feature is no longer scary. Moreover, the program is at least as well organized as before—and perhaps is better at supporting future changes. As Fowler says, “the cumulative effect of these small changes can radically improve the design. It is the exact reverse of the normal notion of software decay” (xvi).
Fear reduction sounds very appealing, and Fowler describes the rationale and process of refactoring in a clear and entertaining way. But what makes this book exceptional is a 265-page catalog of ways to make behavior-preserving changes, each with a motivation, mechanics, and at least one example. We have here a combination of inspiring approach and directly useful nuts-and-bolts practicality that I can only compare to Gamma, Helm, Johnson, and Vlissades’s Design Patterns…and that’s high praise.
This book is most obviously targeted at programmers, who will need a reading knowledge of Java. But I believe software testers who can program should also read it. Developer testing is an essential part of the refactoring process, and Fowler is a programmer who loves testing as much as any of us could. More importantly, as refactoring is becoming more popular, it’s making testing trendy among the better sort of programmers. We testers should jump on this wave and ride it.
Editor's Note: This review first appeared as a "Reference Point" in STQE magazine, Vol.2, Issue 3.
Review By: Niteen Athavale
03/10/2005This book lays a strong foundation for the topic of refactoring, with introductory concepts and terms, followed by disciplined explanations with examples. This book benefits programming professionals the most, as they aim to write exceptional code that requires very few or no fixes. These professionals will enjoy reading detailed examples written in Java. However, the book tries to stay away from language-specific complexity in the examples. As a result, as a reader, you learn refactoring instead of Java. The book caters to both the programmers who want to learn about refactoring and others who want to practice it.
The book follows the writing practices of the “Object Technology Series” that some may be familiar with. It presents concepts with clarity and includes good examples. There are more than forty case studies. The book follows UML notations for consistency.
The book presents very specific techniques for refactoring by evaluating data handling and the complexity of the methods. It teaches you how to simplify data handling by reorganizing it and optimizing the code, by moving segments among methods and up and down the class hierarchy. Many professional programmers have accomplished refactoring over the years by trial and error, but now this book shows newcomers in the programming world how to be a refactorer.
Unlike other books, this one will be on your desk on a regular basis and sometimes will come to your rescue.
How many times have you or your developers thought of revisiting the existing code to improve its design and structure and make it more robust and reusable, even though the application does not need an upgrade? Martin Fowler introduces a disciplined way of refactoring your code. The concept has been around for quite some time, but this book introduces a practical approach to accomplish refactoring—leading to an improved environment for the development and support team to handle small to enterprise-wide applications.
The author explains how to recognize when refactoring is necessary, the benefits of refactoring, and how to refactor without affecting the end users of the applications. The book puts forth the long-term benefits, such as timesaving. The book’s sample refactorings are useful in everyday situations. The author emphasizes that small refactorings will not yield any substantial savings. However, when such refactorings are accumulated in a complete system, the resulting structure is easy to understand, easy to maintain, and provides a code that is extensible.
The author has used an effective and disciplined approach to refactoring. He explains each refactoring example step by step to minimize any side effects and their impact on the overall applications. He uses Java as the programming language of choice in the book. The examples are well written, making it easy for non-Java programmers to implement the process in other languages.