Good design skills => better refactoring

I was pondering this over the weekend. Is refactoring always good?

With the support for refactoring in C# in Visual Studio 2005 and also Refactor! Pro from those awfully nice people at Developer Express, you'd think life is good. We can refactor all we like, all the time.

The problem is, I think, that doing refactoring for refactoring's sake is just not a great way of spending your time. Going back to Martin Fowler for a moment, he says that "Refactoring is the process of changing a software system in such a way that is does not alter the external behavior of the code yet improves its internal structure," and "in essence when you refactor you are improving the design of the code after it has been written." [Page xvi of "Refactoring"]. In other words, in refactoring some code you are not only trying to make sure that you don't change the external effect of the code (where are your unit tests, then?), but you are trying to enhance (improve? clean up? simplify?) the design (or structure) of the code in doing so.

You can't just apply refactorings willy-nilly. You have to have some idea, a hazy design in the back of your mind, that's leading you towards a better structure, cleaner code.

So your guidance in your refactoring exercises should be your knowledge of good design. You should know the Design Patterns, especially important ones like Abstract Factory and Strategy. You should understand the difference between implementation inheritance and interface inheritance, and know when to apply either one and what the benefits and drawbacks of both are. You should have some idea of object-oriented design principles like the Single-Responsibility Principle and Tell, Don't Ask.

In other words, before you can get the maximum benefit from such great tools as Visual Studio and Refactor!, you have some learning to do first. You have to be a good object-oriented programmer.

2 comment(s)
Scott Bussinger
Another negative to "willy-nilly" refactoring is that it can make it hard to look through a file's version control history and really see what the evolution of that file has been. If you see 13 revisions and 7 of them are just refactorings for the sake of marginal improvements it a lot harder to pick out the important points.
18 April, 2006
So, when is refactoring bad? Can it be defined? The core of any good design, not just programming, is consistency.(IMO) I have learned many years ago that it is almost always much easier to correct a problem that was consistently wrong, rather than something, as you stated, is "willy nilly".

Therefore, refactoring can make a problem worse, rather than better, if it destroys consistency. Once refactoring is started, it must be completed throughout... consistently.

25 April, 2006

Please login or register to post comments.