Site Archive (Complete)
Architecture Blog: Refactoring
Architecture & Design
PATTERN LANGUAGE

Modeling, Managing, Making it Right.

by Jonathan Erickson
IF YOU BUILD IT

... Will they Come?

by Arnon Rotem-Gal-Oz
May 02, 2006

Refactoring

Refactoring has become one of the most abused terms I know--right up there with SOA (which I'll probably talk about in another post).

More often than not, I hear people using the term "refactoring" as a sexy synonym for "reworking", as in redesign, rearchitecting, or even completely rewriting.

The original intent of refactoring is best described by Martin Fowler (emphasis in bold added by me):

"Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. Its heart is a series of small behavior preserving transformations. Each transformation (called a 'refactoring') does little, but a sequence of transformations can produce a significant restructuring. Since each refactoring is small, it's less likely to go wrong. The system is also kept fully working after each small refactoring, reducing the chances that a system can get seriously broken during the restructuring."

This is far from your typical rework--not in the sense that you cannot do major redesigns, but in the sense that you use "baby steps" to do that in order not to break the application by introducing too much change at once. Refactoring is a process, a technique--not a redesign.

By the way, TDD really shines when combined with refactoring, as the unit tests work as regression tests, assuring that indeed the system doesn't brake from change to change.

Common refactorings include adding a parameter, renaming classes, extracting methods, and the like. Many of these refactorings are supported by modern IDEs; see "Refactoring with Eclipse or or "Refactoring with Visual Studio 2005's Document Outline Window".

I do wonder, however, why the refactoring catalog on Fowler's site also features major changes like making a solution tiered as refactorings. Making a change like this is bound to have significant impact on the application. When you cross a tier boundary you can't treat code the same way you treat it when it is local--or you start messing with the fallacies of distributed computing (a topic I'll talk about next time)

Posted by Arnon Rotem-Gal-Oz at 06:29 AM  Permalink




 
INFO-LINK


Related Sites: DotNetJunkies, SD Expo, SqlJunkies