Customer Reviews

Refactoring Workbook

5 star:		(3)
4 star:		(3)
3 star:		(0)
2 star:		(0)
1 star:		(0)

 

 

Refactoring is the process of recognizing and correcting problems in code that is functional. Since the code is working correctly, refactoring is something that is generally done late in the development cycle or perhaps not until the code has entered the maintenance phase. However, refactoring has proven to be so valuable that most recent books on software engineering spend some time describing what it is.
Performing a refactoring starts with identifying a "code smell", a segment or feature of the code that just feels awkward or unusual. This is not as hard as it may appear, many of the most common "smells" have been cataloged and the solutions identified. For example, the first "smells" covered in this book are:

* Obscure or overly descriptive comments.
* Overly long methods.
* Overly large classes.
* Overly long parameter lists to methods.

and all examples are coded in Java. Programming veterans will recognize most of these problems as old and venerated programming difficulties. With the exception of large classes, they have been part of the list of bad programming habits for decades. However, the solutions require a bit of thought, it is conceptually simple to make comments, variable names and method names more descriptive, but of course there are reasonable bounds that reasonable people can disagree on. There are only rules of thumb available to guide us, and Wake sets down his thoughts on this matter.
The real difficult problems in this list, and where this book is the biggest help in this section, is in demonstrating how to make methods and classes shorter. To factor out just the right amount of code and still maintain the same level of understandability can be a difficult judgement call. Programmers learn best by seeing worked examples, so the sequence of presentation is:

* Symptoms.
* Causes.
* What to do?
* Payoff.
* Discussion.
* Contraindications.

Coding veterans will most likely find the "contraindications" section of the exercises the most helpful. It describes reasons why performing the refactoring may not be the best decision.
The second set of refactoring exercises are:

* Unnecessary complexity.
* Duplication.
* Conditional logic.

This set of refactorings will also be familiar to coding veterans. Removing dead code, eliminating duplicate code, deleting magic numbers and using more efficient Boolean operations have been on the list of good programming habits for decades. Therefore, the refactorings in this section are fairly routine, as they do not require an object-oriented example to demonstrate them.
The most valuable section of the book is the second one, where the coverage is smells between classes, which are as follows:

* Data.
* Inheritance.
* Responsibility.
* Accommodating change.
* Library classes.

Most modern programmers will be familiar with the first section and will have already done many of them as part of their general coding practices. However, the "smells" in the second list are those that always seem to creep undetected into large programs. Therefore, they are harder to identify and often even harder to remove. I found the segment on problems in library classes to be the most valuable one of the entire book. I often use library classes in Java and there have been times when I have looked at a library class and been puzzled by how it is constructed.
The book closes with four small programs that are to be refactored as exercises. Large and complex enough to be worthwhile exercises, they are an excellent conclusion to a helpful book. Many problems are included and solutions to almost all are found in an appendix.
While this book is a good way to practice refactoring, it is not a good way to learn it. The classic book by Martin Fowler is still the best introduction to refactoring.

An ideal companion to Martin Fowler's Refactoring book. Wake delivers a more practical oriented book, with a generous amount of relevant examples and code listings. Compared to Fowler's seminal title this one, due to its "workbook" nature, is much more Java-centric, making it harder to translate certain concepts to different languages and environments. In my opinion a very interesting and informative book, somewhat affected by a confused typographical layout not very well suited to its content. Just remember to read Fowler's book first!

Most books about programming teach us about a specific technology or two. Right now I'm staring at some great books on my shelf that have taught me things like user interface programming in Java, templates in C++, how to work with XML files, and so on. Bill Wake's "Refactoring Workbook" goes well beyond books like these. Those books give me some fleeting insights into a technology du juor. Wake's book teaching me things that will stay with me throughout my career. I finished it having learned new skills that will make me a better programmer, regardless of what I'm working on-Java user interfaces, C++, or code to read XML files.

The book includes over 100 exercises, many of which are answered in an appendix. I worked through the book alone but this is the type of book I'd love to work through with a group.

The concrete identification of smells, working examples, and straighforward but useful exercises make this book a must-have to really understand how to refactor your code -- even if you're a non-Java guy like myself.

It would've been nice to have examples inline for some of the refactorings -- more of the feel of _Design Patterns_. I also didn't agree with him everywhere; he asserted that there were some smells that had no known justitications and had to always be addressed. However, unit tests look like they would set off his 'too much internal knowledge' smell, but I probably wouldn't just go chopping them out because of that.

Learning to make what you already have better WITHOUT negatively impacting the enterprise or rewriting what you already have is a key skill that this book teaches and preaches. Understanding what it means to successfully refactor something is well worth the effort, especially if you are interested in getting into the world of service oriented architecture.

Services can be refactored after they are deployed because they can maintain a consistent external interface or contract that others form dependencies to. THis allows us to apply the concepts and techniques described in this book in order to build not only increasingly robust code but also increasingly valuable code in the form of reusable services.

The author does a good job of organising the content and explaining the application through examples. This book is helping my team with a specific project that requires us to revisit but no rewrite a collection of existing components.

This book proved to be an excellent learning tool during a refactoring session at my eXtreme Programming Users Group meeting. We discussed most of the covered refactorings, divided into pairs, and went through several of the exercises (many of which had downloadable code). Thereafter, each pair discussed their approach with the entire group. I must say the book accomplished its goal: To give novices and veterans alike the chance to gain or sharpen refactoring skills. I highly recommend this book and suggest its use within a group.