In a previous job I was on a team involved doing just this, only the original code was crufty but not really awful like yours. To improve things, a programmer on the team drew up a plan for a complete object-oriented redesign. This involved these steps:
- Breaking up the system into objects/classes
- Cataloging all of the scripts that would have to be
re-written using the new design
- Formulating a plan/project schedule for completion of
all of these modules and scripts, in a logical order based on what modules use what other modules
- Writing the API for each class, i.e. some basic POD for all the API calls, just listing what arguments are required/expected and what would be returned
- Writing tests for each API call
- Beginning to fill in the empty API methods with real code, and running tests as you go
- Constantly revisiting the OO API, tweaking it when it was realized that we forget something or that something was unnecessary or belonged to a different (or even new) class, and changing the tests to match the API changes
- When a module/script passed all tests, fully documenting the POD
This is, of course, very oversimplified, especially the order. The steps weren't done as discretely as this list sounds; the project schedule wasn't really done until after the basic API POD was written, and kept being adjusted; etc. We used CVS. The API POD was passed through a pod2html variant, so there was an easy reference to it all with a browser.
-- Frag.