TITLE: Refactoring, Beyond Software
AUTHOR: Eugene Wallingford
DATE: August 28, 2007 9:44 PM
Today I "refactored" the web page for a class session,
along with files that support it. I used scare quotes
there, but my process really was affected by the
that we do to our code. I can probably describe it
in terms of code refactorings.
Here is what I started with: a web page that loads
thirteen images from a subdirectory named
session02/, and a web page that loads two images
from a subdirectory named session03/.
Due to changes in the timing of presentation, I needed
to move a big chunk of HTML text from Session 3 to
Session 2, including the text that loads the images
In the old days, I would have cut the text from Session 3,
pasted it into Session 2, renamed the images in
session03/ so that they did not clash with files
in session02/, moved them to session03/,
and deleted session03/.
Along the way, there are a number of mistakes I could make,
from inadvertently overwriting a file to losing text in
transit by bungling a few keystrokes in emacs. I have
done that before, and ended up spending precious time
trying to recover the text and files I had lost.
I did something different this time. I didn't move and
delete files or text. First, I copied text from one page
to the other, allowing Session 2 to load images from the
existing session03/ directory. I tested this
change by loading the page to see that all the images
still loaded in the right places. Only then did I delete
the text from Session 2. Next, I copied the images from
session03/ to session02/, using new names,
and modified the web page to load the new images. I tested
this change by re-loading the web page to verify the lecture.
Only then did I delete session03/ and the images
Everything went smoothly. I felt so good that I even made
a subdirectory named sample-compiler/ in the
session02/ directory and moved the images in
session02/ associated with the sample compiler --
one of the original session02/ images plus the
two originally in session03/ -- down into the
new subdirectory. I made this change in a similarly
deliberate and safe way, making copies and running tests
before removing any existing functionality.
When I got done, I felt as if I had applied to common
The steps were remarkably similar.
My description may sound as if this set of changes took
me a long time to effect, but it didn't. Perhaps it
took a few seconds longer than if I had executed a more
direct path without error, but... I moved much more
confidently in this approach, and I did not make any
errors. The trade-off of deliberate action as insurance
against the cost of recovering from errors was a net
I refactored my document -- really, a complex of HTML
files, subdirectories, and images -- using the steps
like those we learn in
small, seemingly too small in places, but guaranteed to
work while "passing tests" along the way. My test,
reloading the web page and examining the result after
each small change, would be better if automated, but
frankly the task here is simple enough the simple
"inspect the output" method works just fine.
The ideas we discover in developing software often apply
outside the world of software. I'm not sure this is an
example of what people
except in the broadest sense, but it is an example of
how an idea we use in designing and implementing programs
applies to the design and implementation of other
artifacts. The ideas we discover in developing software
often apply outside the world of software. We really
should think about how to communicate them to the other
folks who can use them.