Home > View Post

Refactoring and Design

I'm currently reading Martin Fowler's book Refactoring: Improving the Design of Existing Code and I'm about a third of the way through.

Book Cover - Refactoring: Improving the Design of Existing CodeIt was on page 66 that I came across a small section, just two pages, called 'Refactoring and Design' that really resonated with me. I'm a big fan of some of the Agile tenets such as "deliver early and often" and the importance it places on collaboration. However, one aspect that has never sat well with me is how many agilers argue that Agile (particularly XP) negates the need for any design (you may remember my post about garden sheds).

Martin starts on Refactoring and design:

"Refactoring has a special role as a complement to design. When I first learned to program, I just wrote the program and muddled my way through it. In time I learned that thinking about the design in advance helped me avoid costly rework. In time I got more into this style of upfront design."

He then goes onto explain how it is often argued, particularly by those that support XP, that refactoring can be an alternative to upfront design and says:

"Actually, this approach can work. I've seen people do this and come out with a very well-designed piece of software"

However, "Although doing only refactoring does work, it is not the most efficient way to work.".

And this is the part that I think really hits home:

"With refactoring the emphasis changes. You still do upfront design, but now you don't try to find the solution. Instead all you want is a reasonable solution. You know that as you build the solution, as you understand more about the problem, you realize that the best solution is different from the one you originally came up with. With refactoring this is not a problem, for it no longer is expensive to make the changes."

I couldn't agree more. Upfront design isn't the be-all-and-end-all, you have to be willing to change. You should have some upfront design to satisfy what you do know. Refactoring and unit tests make it easy to make the changes when you need to.

It's an interesting book, if not the easiest thing I've ever read. Anybody who spends a lot time reviewing code and often 'feels' that something is wrong but can't put their finger on exactly what, will appreciate the library of smells and solutions it offers.

Tags: Other

 
Josh Post By Josh Twist
3:42 AM
04 Apr 2006

» Next Post: Flexibility in Software
« Previous Post: Check ThreadPool levels

Comments are closed for this post.

© 2005 - 2017 Josh Twist - All Rights Reserved.