When Making a Comprehensive Retrofit of your Code...

chizor asks: "My programming team is considering making some sweeping changes to our code base (150+ perl CGIs, over a meg of code) in the interest of consistency and reducing redundancy. We're going to have to make some hard decisions about code style. What suggestions might readers have about tackling a large-scale retrofit?" Once the decision has been made for a sweeping rewrite of a project, what can you do to make sure things go smoothly and you don't run into any development snags...especially as things progress in the development cycle?

Comments

If it aint broke...

[ZaneMcAuley]

Dont break it.

Seriously, yes I understand there are maintenance costs involved in maintaining old code but really, I believe the statistic is that for every 10 times uou modify a part of code, a new bug is introduced.

How often is that code hit during a maintenance cycle? How problematic is that code?

First Modularize, Then rewrite?

[nonlucent]

This is just an idea, I have no actual education on this subject. I do have a good amout of experience working with old, uncommented code- some of which didn't even have an initial design ( verbally gave some contractors 'a good idea' of 'what it should do') ! Anyway- here it is; first break up your EXISTING ugly code into a proper grouping of modules and functions ( your new design, maybe with some extra small functions for easy debugging ), keeping all the nasty little tricks added to fix the nasty little(big) bugs. Then, rewrite each little function one by one; after each fix, checking the output of a good automated tester is handy! Otherwise a whole QA cycle is required, but this IMHO is a _safe_ , if somewhat painful method, that gives you better options in terms of bugfixing/adding features at the same time( bullshit? maybe! ) since the 'in-between' code will (often/sometimes/probablynot) still work.