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!

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!