Programming: Coming Up For Air

At work I'm working on a big refactoring effort that has some really crufty code.The underlying problem is that it's a 3K-line class with functions that are sometimes a few hundred lines each. To top it off, there's a few thousand more lines buried in some related classes.The goal of this is to "make it fast."Originally the thought was to just rewrite it. Asymptotically that's likely what's going to happen... but a rewrite has it's own problems. When you rewrite you need to know what it is that you are writing. You're up against the same problem as before: you have a few thousand lines of code that you still have to reverse engineer.My course of action is to try to break this big problem down into smaller pieces. Not just that but to try to stabilize the system at each checkpoint.Why? Simple: to not go off in the weeds. If there were unit tests around the code you could use that as a set of guideposts to make sure y ou don't go off the grid too much, but this is crappy legacy code. Retrofitting unit tests on this particular code would be somewhat nightmarish so that's not really that much of an option.Piecemeal:

1. Reformat and superficial refactoring. This gets rid of variables called "aaa" for instance. Enforce naming conventions to help to understand what's where.
2. Profile the code. Optimize and simplify where possible.
3. This particular code is reporting. It has a craptastic intermediate format in DataSets. Step 3: rationalize the data structure. The data is being read in the same way, but the processing targets a different representation.
4. Make the data reading code populate the data structure in #3 directly without loading it into yet another DataSet.

At every point the code becomes testable. At every point you can fix a problem before it gets too big. The assumptions you make can be corrected.What this prevents is a big "Ta-Da" moment with brand new code. If you go down a path with a wrong assumption... well that's where schedules are blown. The other giant upside is that you are constantly delivering improved functionality and making visible progress. You have the opportunity to come up for air occasionally to make sure you're on the right track.This same scheme can be used just about anywhere you have crap code. Try to break it up, however impossible seems at first.I wanted to have something positive to write instead of just pointing out antipatterns all the time.  :-)