Refactoring: Improving the Design of Existing Code (The Addison-Wesley Object Technology Series) by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts
Read more about this title…

This book is awesome and a must read for anyone who enjoys the art of refactoring as much as I do. The examples are crystal clear and the way the refactorings are done step by step makes it so much more understandable.

Here are a few excerpts that I enjoyed from this book.

“The problem with copying and pasting code comes when you have to change it later. If you are writing a program that you don’t expect to change, then cut and paste is fine. If the program is long lived and likely to change, then cut and paste is a menace.”

I’ve got to agree and disagree with the above statement. I think anytime you find yourself copying and pasting is a clear sign of duplication which should be improved. Removing duplication should be something we all strive for, and remember that inheritance is not the only way to remove duplication. Proper object composition, delegation and generics are all great ways to remove duplicate code.

Replace conditional with Polymorphism has to be by far one of my favorite refactorings. If you’re seeing if-else statements scattered throughout your code base that’s a smell. Switch’s are no better… (booo switches…)

“Is renaming worth the effort? Absolutely. Good code  should communicate what it is doing clearly, and variable names are a key to clear code. Never be afraid to change the names of things to improve clarity.”

Amen, brother! Thank goodness for tools like Resharper and Rhino.Mocks. On my current project we’re using NMock2 and I got burned several times doing a Rename Method because of the string literals used in NMock tests… My advice is just use Rhino Mocks… please… for my sake!

“You write code that tells the computer what to do, and it responds by doing exactly what you tell it. In time you close the gap between what you want it to do and what you tell it to do. Programming in this mode is all about saying exactly what you want. But there is another use of your source code. Someone will try to read your code in a few months’ time to make some changes. We easily forget that extra user of the code, yet that user is actually the most important.”

“The first time you do something, you just do it. The second time you do something similar, you wince at the duplication, but you do the duplicate thing anyway. The third time you do something similar, you refactor.”

I often heard the term “smell” used as a way to describe something funky in a code base or team but I had no idea where the term came from… until know!

“If it stinks, change it.” - Gradma Beck, discussing child-rearing philosophy

The chapter on code smells is awesome, it’s offers a catalog of code smells like:
* Duplicate Code * Long Methods * Large Classes * Long Parameter Lists * Divergent Changes * Shotgun Surgery * Feature Envy * Data Clumps * Primitive Obsession * Switch Statements * Parallel Inheritance Hierarchies * Lazy Class * Speculative Generality - “Oh, I think we need the ability to do this kind of thing someday.” * Temporary Fields * Message Chains * Middle Man * Inappropriate Intimacy * Alternative Classes with Different Interfaces * Incomplete Library Classes * Data Classes * Refused Bequest - “Subclasses get to inherit the methods and data of their parents. But what if they don’t want or need what they are given?” * Comments

If you only read one chapter in this book, I suggest Chapter 3. “Bad Smells in Code”. I really like how Resharper uses the same refactoring names as those mentioned in this book. Anyway’s, what are you waiting for go read this book.

comments powered by Disqus