Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic
 
PerlMonks  

Strategies for maintenance of horrible code?

by converter (Priest)
on Jul 12, 2006 at 05:21 UTC ( #560614=perlquestion: print w/ replies, xml ) Need Help??
converter has asked for the wisdom of the Perl Monks concerning the following question:

For the past several months I've been busy rewriting the horrible perl code left behind by my predecessor. His approach to development was "Write some code. If the code runs without revealing any of the damage it's done, ship it. If not, write some more code." This code is so bad that when co-workers ask me what I'm working on, I tell them "The Madman's Diary." Yes, it would have been cheaper and faster to throw this code away and start over, but I wasn't given that option.

My latest assignment is the repair of a tangled mess of a show-stopper that was discovered in a product that was supposed to ship today. After adding an open() override that logs the arguments to open() and some quality time with the watch(1) utility observing changes to the files containing the data that are causing the problem, I've narrowed the list of suspects down to a couple in-house scripts and a few (probably altered) webmin modules.

Now that I know where to look, I'd like to identify as quickly as possible which details can be safely ignored. I plan to use Devel::DProf to produce an execution graph for reference and Tie::Watch to watch variables, but I wonder if there are other tools that I should look at. A utility or module that would allow me to incrementally build a profile with persistent notes would be wonderful.

Debugging this code is a whole different game, and I'd really appreciate some input from other monks who've dealt with this type of problem.

Comment on Strategies for maintenance of horrible code?
Re: Strategies for maintenance of horrible code?
by Anonymous Monk on Jul 12, 2006 at 06:40 UTC
    Ignore nothing. Whats the nature of the problem?
Re: Strategies for maintenance of horrible code?
by GrandFather (Cardinal) on Jul 12, 2006 at 07:39 UTC

    What tools are you using already and on what platform? For a large range of "detail" debugging there is nothing like as good as an IDE with a good integrated debugger. For a higher level view of where things are going Devel::TraceCalls may be handy, although it's output can be rather voluminous.


    DWIM is Perl's answer to Gödel
Re: Strategies for maintenance of horrible code?
by adrianh (Chancellor) on Jul 12, 2006 at 07:49 UTC
    Debugging this code is a whole different game, and I'd really appreciate some input from other monks who've dealt with this type of problem.

    I'd recommend reading Perl Medic and Working Effectively with Legacy Code (the latter isn't Perl specific - but is chock full of useful advice).

    I would not spend any time fixing the code if it's not breaking (assuming you're not being paid to review/fix the code). However evil it may be - if it's doing it's job leave it alone.

    Instead - every time you need to fix a bug or add some new functionality just test/refactor the bits of the evil code that are touched by the changes. I've found incrementally adding tests and refactoring to be much more effective than any sort of "big bang" fixing things for the sake of them approach :-)

    If you are being paid to do a review/fix then Perl::Critic might give you some useful places to look.

      Definitely agree about the approach of sorting things out with gradual refactoring and tests as the need arises. The problem with the "Big Bang" approach is that you have the potential for a very long stretch of time where there are two forks of the code: ugly shipping code that will need to be fixed and refactored as bugs are reported, and pretty nonfunctioning code that will need to incorporate those fixes as they are uncovered, resulting in a perpetual loop of "it's not quite ready yet."
Re: Strategies for maintenance of horrible code?
by eyepopslikeamosquito (Canon) on Jul 12, 2006 at 08:30 UTC

      Actually, just writing the tests is often a damn fine way of finding bugs. No exactly what OP is after at the moment, but something that is at the forefront of my mind because I'm in the middle of writing a set of tests (in Perl :) for some XML processing C++ code and turning up a pile of bugs as I go.

      However it does suggest another test avenue: write test harnesses for modules so that you can exercise them in isolation and better understand how they work. If the test harness ends up part of a regression test system so much the better.


      DWIM is Perl's answer to Gödel
      Maybe. For another point of view, see Joel Spolsky on not rewriting from scratch.
      uh oh. why does this remind me of perl 6? =)
Re: Strategies for maintenance of horrible code?
by Ovid (Cardinal) on Jul 12, 2006 at 10:37 UTC
Re: Strategies for maintenance of horrible code?
by Moron (Curate) on Jul 12, 2006 at 12:13 UTC
    Some basic CYA I can see:

    1) Ensure there is sufficient functional and technical design documentation against which the routines can be tested.

    2) (updated) Make sure there is a sufficiently detailed project plan to include tasks for: systems analysis, functional and technical design, test planning, test script writing (e.g. using Expect), developing, unit-, integrated and functional testing, rework and implementation, to include a GANTT chart of the work done so far and by who to what % of completion, to avoid getting the blame for not meeting poorly conceived targets over which you had no control.

    In response to formal testing against the plan, I find it a useful aid to bug-fixing to monitor execution with perl -d, setting breakpoints and examining variables to hunt down which line of code causes each failure.

    -M

    Free your mind

Re: Strategies for maintenance of horrible code?
by aufflick (Deacon) on Jul 13, 2006 at 00:17 UTC
    You might find the comments to my recent question Generating documentation from Perl code (not just POD) useful.

    The Doxygen perl extension creates docs that are great for seeing what classes re-implement what methods etc. Also the UML::Sequence sounds intriguing - it pupports to generate a sequence diagram by monitoring code execution.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://560614]
Approved by Old_Gray_Bear
Front-paged by Old_Gray_Bear
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (19)
As of 2014-10-20 14:02 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (77 votes), past polls