Friday, June 8, 2012

Legacy refactor jitters


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.