Refactoring: Improving the Design of Existing Code Book Review

Technorati Tags: ,

I’ve long been told that this book is one of the must-reads for developers. After picking it up a few months ago, it took me a while to finish reading it. Having gotten through 3/4 of the book, I’ve decided that it’s good enough to give it a decent review.

The first thing that drew me to the book was that it was written by Martin Fowler. His preface struck me was the emphasis on a set process for refactoring. I consider myself a fairly competent developer and refactoring was something I did fairly often. Or so I thought. The way I was approaching refactoring was not systematic or repeatable.

As I read further into the book, I worked through the examples of how refactoring worked but one basic thing stuck with me. When you refactor, you do it in a systematic and repeatable way. The main emphasis was that you NEVER added new functionality when refactoring existing functionality. You only add new functionality when you finish refactoring your existing code base.

This impression I got from the book, so far, was that it was extremely pragmatic and logical. The steps which Fowler walks you through, when refactoring, are extremely basic and easy to follow. As you progress through the chapters, he builds upon the concepts which he has laid down before and the learning curve is fairly smooth and gradual. While I am not finished yet, I found this to be an easy read and quite enjoyable. The examples that he presents are practical and easy to adapt to real life situations. Though I am far from one of the movers and shakers in the IT industry, my two cents is that this book is a definite must-read. The next book I need to finish – after I got sidetacked – is Eric Evan’s Domain Driven Design. So far I found it to be slightly harder to follow as it’s a fairly heavy read.


2 Responses to “Refactoring: Improving the Design of Existing Code Book Review”

  1. Hi Alvin!

    I’m working my way through this one at the moment. Its interesting how much contrast there is between the approach to refactoring that Fowler describes and the approach that most developers evolve to as they learn the practice of refactoring in their day to day work. I don’t think I’ve ever seen anyone apply a refactoring with as much discipline as this book encourages! While I can’t ever see myself being so rigorous, there is certainly value in that the book is at least pushing me in the right direction.

    DDD is indeed a heavy read, but definately a worthwhile one. Keep at it!

  2. 2 alvinyong

    Hiya Paul,

    It’s a good read. One thing that I’m actively trying to adopt is some of the basic steps such as not adding functionality when I’m refactoring and also learning to identify the occasions when I apply different methods such as the extraction, substition and inline methods.

    Fowler offers some really valuable insight into refactoring and it’s not just focused around making code more aesthetically pleasing and extensible. He addresses the issue of performance, albeit briefly, and advocates that there are times when you sacrifice readability for performance. In his words, the advancements in hardware merely “shift the goalposts.”

    I think I’m going to read DDD in spurts. It’s definitely not bedtime reading so I think I’ll take the approach of reading it in small chunks and try to digest what I’ve read before continuing.

    Good to hear from you, again, Paul! Please keep posting!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: