2001/12/19

I'm still working my way through a pile of books I bought with the purpose of updating my list of recommended books.  One of these days I'll get to the bottom of the pile and update the recommended list. All in good time!

FogBUGZ 3.0 Development

The FogBUGZ 3.0 development process is in full swing now. One of our first priorities is to refactor and clean up some of the code. There were a bunch of places with duplicated or almost-duplicated code; our logic wasn't cleanly separated from the UI; the HTML we generated was based on ancient browsers. It's the kind of project that would tempt a lesser programmer to "throw it out and start from scratch." Instead, we're going through the code one file at a time, cutting and pasting blocks, scrubbing the HTML (to use fully-XHTML valid code with all formatting isolated style sheets), and creating new classes for underlying logic that used to be scattered all over the place.

In the ideal world, when you refactor, you simply apply almost mechanical transformations to an existing code base that can be clearly understood to have no effect on the correctness of the code. The simplest example I can think of is changing "if not x then A else B" to "if x then B else A". You know that you can always do such a thing without breaking the code, and if it's a little clearer to read, it's a safe fix.

Here's a typical thing that happens. As I go through the code, I'll find some SQL statement in the middle of some HTML. So I create a class and give it a method that executes the SQL statement, and call that method from the HTML. I'll start with the old SQL code and move it into my new class unchanged. Then I'll look at that class for opportunities to apply more simple, bite-sized transformations that make it cleaner or faster. In the principle of eating our own dogfood, all daily changes go up on our internal bug database right away. Because we're refactoring rather than starting from scratch, at any given time we always have a working version of FogBUGZ checked into CVS. In the worst scenario, we've introduced a small bug.

The best time to refactor is at the beginning of a development cycle. That gives you the maximum amount of time to catch any bugs that you introduced accidentally.

In the ideal world, we would have strong unit tests so that we could convince ourselves that nothing was broken that used to work. As we applied transformations, the unit tests would tell us automatically if we had broken anything and we could probably stay at zero bugs throughout the process. This is one of the valuable principles of Extreme Programming. We haven't created unit tests yet, because all the HTML->XHTML+CSS cleanup that we're doing makes FogBUGZ's "correct" output a rapidly moving target. As the output stablizes, we'll build unit tests. We did not follow the XP principle of writing unit tests first, because it is so much easier to (a) write the code (b) hand-check the HTML that it produced (c) use that HTML as the basis for the unit test. If you do things in the XP order you have to figure out character-by-character what your output HTML is supposed to look like in advance, which strikes me as mind-numbingly tedious and a serious waste of time.

My new book is here! Apress has just published a new collection of 36 essays from Joel on Software, aptly named More Joel on Software. Get yours today! Available from Amazon.com or wherever fine cheese is sold.

About the Author: I’m your host, Joel Spolsky, a software developer in New York City. Since 2000, I've been writing about software development, management, business, and the Internet on this site. For my day job, I run Fog Creek Software, makers of FogBugz—the smart bug tracking software with the stupid name, and Fog Creek Copilot—the easiest way to provide remote tech support over the Internet, with nothing to install or configure.

Enter your email address to receive a (very occasional) email whenever I write a major new article. You can unsubscribe at any time, of course.