I just committed my first complete refactor of legacy code
in a long while. Broke it apart, added
tests (based on the original code), rewrote it (based on the new tests), and
now have very little way to verify it worked.
It’s kind of weird.
If the rewrite works correctly, there’s no way to tell anything
changed. That’s kind of
anti-climatic. If there’s a small
problem, we’ll see a small difference – at some point (hopefully sooner than
later). If there’s a big problem, we’ll
see a big difference – probably soon. It’s
an unsatisfying feeling – waiting for nothing to happen. Is it not being used? Is it working great? Or is it working subtly incorrectly but noone’s
noticed yet?
This section of code followed the book (Working Effectively with Legacy Code, Michael Feathers) for refactoring
legacy code almost perfectly. There were
thankfully convenient, simple seams to break into. I was able to isolate the code, smash it
apart, and rebuild it in small individual parts using TDD. It all went exactly how the books say it
should.
Except of course for not being able to put any tests around
it beforehand to make sure I didn’t totally FUBAR it.
Is it always this unnerving?
Why doesn’t anyone (besides this half-attempt) blog about the psychological
side of swdev? My QA’s about to ask me
how to verify it worked, and the best I can tell him is “if it works the same
as before, it’s good. Except for that
little part that didn’t quite work right before that prompted this change –
that part should work a little better now.”
I’m sure I’ll be revisiting this topic (and this section of
code) in the future.