Refactoring Legacy
I've decided to apply some XP practices to an old web start application. Old being from 2001, so 3-4 years. And I must say this code reeks! Which is probably a good thing. How good would it be if I pulled out this code and started admiring how it was written and designed?
I think I hacked this together in a few days. Which means there are no comments in the code and it was not well designed. But it worked. Which isn't a good thing, unless all you care about is working code (and not maintaining it). I imagine most business people think they only care about working code...
Anyway, I started with 3 classes. My first order of business was to start retrofitting some unit tests on the code. Alas, lack of design was making this near impossible without some major twister playing.
So, I started to refactor to enable fitting some unit tests on the application. And I got addicted to the refactoring! I have never gotten so much satisfaction out of writing code. But I wasn't writing code. I now have 9 commented classes, mostly between 100-150 lines of code and no new functionality, but no superfluous code either. I did manage to introduce one bug, reminding me why I started doing this in the first place.
Refactoring is good, but only with unit tests or treading very, very, very carefully. If you are going the careful treading method, my experience says get off the treading carefully as quickly as you can. Though I really don't want to at this point.
All this is given me some good insight on testing and design as well. I can see how sketching a design is a really good thing and BDUF, which is something I'm guilty of doing even on an unconscious level, is a sin. A bad sin.

0 Comments:
Post a Comment
Links to this post:
Create a Link
<< Home