Refactoring for fun and profit
24 August 2005

My free development time, this week, has been spent refactoring the SGX core so that my Zinc home automation project, and my 3D engine, can use the same base[0]. I haven't finished it yet, and there's still a long way to go, but I have to stand up and say "refactoring is fun!"

There, I said it. I'm an addict.

But why is it fun? Well, it's a chance to revisit old friends. Code you haven't seen for years (my core engine is nearly 10 years old!) suddenly arrives in your editor and you think wistful thoughts. You get to fix those niggles you didn't last time around, and you're able to implement better solutions because your skill has increased since you first wrote it. This sense of achievement, and of having progressed, is fun.

But why is it profitable? Because you learn. In truth, you revise. Developing any project over a long amount of time will cause you to forget things. A refactoring will cause you to remember or learn those things, giving you a better "big picture" idea of the project and inspire you with new confidence in the project as the flakely bits are isolated and added to your TODO list. The minutea of assumptions made within old functions can be verified and checked. And all the bugs that rely on these assumptions will disappear. Face it: bugs exist because something you thought was true - isn't, and this eliminates that.

In fact, refactoring is so much I propose some bi-annual refactoring time (BART) for any large project. So let me re-start: My development time, this week, has been spent doing a Simpson... :)

[0] They started using the same base, but grew apart when I refactored part of the code to make the structure of the book flow better.