in reply to Analyzing large Perl code base.

The earlier advice from others re writing tests and re-factoring is sound. You are, however, most unlikely to be given enough time to do it all, so you must choose wisely which code to clean up first. How to choose? i) write tests for all recent (and new) bugs; ii) focus on modules you consider to be most vital and highest risk; iii) Go through the user manual and write a test (and refactor where appropriate) for each example given there (i.e. focus on client view of the system). Perhaps more important is to ensure that all new code is developed test-first and with a solid test suite.

I've been (and am still going) through something similar as mentioned in What is the best way to add tests to existing code?. As expected, and despite earlier assurances, I did not get anywhere near the time and resources I would have liked. Bottom line: this sort of code cleanup, while strategically sound in the longer term, does not bring in immediate revenue.

Update: You might pick up some good ideas from the book Perl Medic by Peter Scott. Ditto from the node starting to write automated tests.

Replies are listed 'Best First'.
Re^2: Analyzing large Perl code base.
by dmitri (Priest) on Jun 29, 2005 at 21:50 UTC
    I picked up that book several weeks ago, and it's great. I also recommend it to everyone doing Perl code maintenance.

    A stab at reviewing the book is taken here.