artist has asked for the wisdom of the Perl Monks concerning the following question:

I don't have developer's experties available to explain the code, but the code looks good, and nicely done with comments, for around 3000 lines in single file. It was maintained for many years. How do I extract the logic and draw some type of visual diagram, so I can explain it easily to other people and can maintain it for long time, without storing way too much information in my head.

Thanks!

--Artist

Replies are listed 'Best First'.
Re: Model the Logic in existing code
by davorg (Chancellor) on Jul 19, 2005 at 15:54 UTC
Re: Model the Logic in existing code
by Transient (Hermit) on Jul 19, 2005 at 15:37 UTC
    This is what UML is for. Try a data flow diagram or (good luck) use cases. Visio helps
Re: Model the Logic in existing code
by adrianh (Chancellor) on Jul 19, 2005 at 21:57 UTC
    I don't have developer's experties available to explain the code, but the code looks good, and nicely done with comments, for around 3000 lines in single file. It was maintained for many years. How do I extract the logic and draw some type of visual diagram, so I can explain it easily to other people and can maintain it for long time, without storing way too much information in my head.

    Random ideas:

    • 3KLOC isn't very much. If the code's as nice as you say you should be able to sit down with a hardcopy for a few hours and get a pretty good idea of what's going on.
    • Sit down with a whiteboard and explain it to the new developer. If you think you're going to have to do this a lot then videotape it.
    • Tests, especially acceptance tests, are a really good way to show what the code does. You do have a test suite don't you :-)
    • Look at tools like Autodia and SQLFairy that can automatically generate diagrams from code/schema. That way you don't have to spend time and effort keeping diagrams and code in sync.
Re: Model the Logic in existing code
by castaway (Parson) on Jul 20, 2005 at 12:20 UTC
    Assuming (hoping!) it has subs, work from the bottom up, find each sub, figure out what it does, then figure where it gets called from and why etc etc.. You should end up with a nice tree like model.

    C.