Refactoring Is Not Design

ReFactoring, supposedly "improving the design of existing code", is to design what walking is to mapping. When you take a walk, you might see a pretty bird on a tree and offer it some corn. Or you might step in dog droppings and whip out a plastic bag to clean them up. You might start a riot, kiss a girl, or perform many of the important observation and maintenance tasks explained by DoctorSeuss on Mulberry St.

In other words, in Refactoring you've honed your work, communicated with your peer programmers, and made your shared world just that little bit brighter. You began with code and you ended with code - and if you've done it right, it's better code. After all, if TheSourceCodeIsTheDesign then ReFactoring is, as it should be, just "improving existing code".

The process of design is (up front) performed in the absence of code. It needn't begin with code and it needn't end with code. It's documentation of the intent of code. It begins as an answer to analysis - which, at its most concrete, is merely an AcceptanceTest - and it ends with parameterization and combination of elements of technical architecture. It tells you you should go to Mulberry St, but it doesn't tell you what you'll do there. So it's like making maps of all the places you might go, rather than actually going and then doing.

Different gazintas, different gazoutas, different experience; so now I believe the old choice on RefactorOrDesign was forced. This is to say, it loses the community aspects of ReFactoring. So: Listening, Testing, Coding, and ReFactoring - that's all there is. Anyone who says different is selling - or buying - something.

Where does the formulation at the top of the page get us? <gerund naming the action of applying a fairly well-specified class of transformations on code> is not <desperately vague abstract noun with a huge halo effect that everyone wants a slice of>. Are we done?

Meanwhile, consider this description of the design[ing] activity:

the process of inventing things which display new physical order, organization, form, in response to function... -- ChristopherAlexander, NotesOnTheSynthesisOfForm

So, taking "inventing things" at face value, some refactorings (such as ExtractClass) have a excellent claim to being the manifestation of design thinking - let's say, it becomes recognized that some responsibilities are spread around a little too much, and that pulling out a class to meet them all in one place will make a bunch of stuff easier to understand (=> easier to change, maintain etc). You can now argue the toss as to whether this is ResponsibilityDrivenDesign expressed through refactoring (the one-line description of ExtractClass includes a weasel-word: "relevant") or the plain magic of refactoring itself. Or something between (combining) the two

Then again, something like PullUpField? perhaps has a rather weaker claim to being a manifestation of design by itself, although it isn't hard to imagine such a thing being part of a sequence of refactorings that do manifest design - perhaps marshalling the "relevant" things into an agreeable place from which they might be extracted.

Back at the larger scale, ExtractPackage? looks very much like design, too.

But these are all somewhat sterile, self-serving operations by the programmer, for the programmer. Alexander's description of design states that it is done "in response to function". Well, refactoring supposedly follows the addition of new passing tests which (in TDD-land) are justified by the next unmet requirement.

Now consider WhatIsAnAdvancer, where Ward states that advancers were discovered two years into maintenance. (Actually, it looks a lot as if Ward understates the case there; discovering advancers looks mightily like EmergentAnalysis?.)

Looks like just reinventing functors to my untutored eyes. As to "in response to function", design in a waterfall is done in response to analysis. Testing, in a waterfall, is "in response to function". Not blessing waterfall, but it seems Alexander's definition doesn't account for it.

RefactoringIsRetrospectiveDesign? - almost every process I have refactored when maintaining other people's code has revealed the design of the aspect I have been interested in. The design was there, but difficult to see. Often, the "worst programs" - the really huge ones - are inspirations, written by gurus. But only understandable by the gurus without refactoring. -- PeterLynch

Might there be some confusion here between design of code (how we put pieces together to do what we want) and analysis of requirements (deciding what we want, or, to use a phrase above, "documentation of the intent of code")?

JuneZeroFive

CategoryRefactoring

EditText of this page (last edited June 28, 2006) or FindPage with title or text search