Book Review - Refactoring

This is a book I read a few years ago. It is a very useful book. It’s considered a classic in software engineering literature because it introduced the idea of code smells and because it gave names to a bunch of common refactorings.

Code smells are things that indicate that there might be a problem with your code. It’s kind of like when you open your refrigerator and the smell reminds you that those leftovers from last week are probably no longer good. The smell just kind of jumps out at you. So do code smells. In both cases, it requires a little investigation to determine what the problem is or if there really is one. Some common code smells are duplicated code and large methods or classes. They are immediately obvious and often indicate some sort of problem.

Naming refactorings is very important. It allows us to communicate very clearly. Here is a whole catalog of them. Some common ones include extracting classes and methods and renaming fields. We all refactor all the time but having some common terminology enables greater understanding and communication.

I went into reading this book looking to learn how to deal with legacy code. It does have some good tips for that. However, my biggest revelation was the impact that refactoring can have on the design process. By mastering refactoring our designs no longer have to be perfect, and can become more flexible. When we have confidence we can refactor, then we don’t have to design features in up front. We simply add them when and if we need them.

I enjoyed this book so much that I wrote a whole presentation about it, which I gave at the original GDevCon. Here it is. Enjoy.