Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

Re^2: Analyzing large Perl code base.

by gellyfish (Monsignor)
on Apr 15, 2005 at 10:05 UTC ( #448117=note: print w/ replies, xml ) Need Help??


in reply to Re: Analyzing large Perl code base.
in thread Analyzing large Perl code base.

To be fair, I think you probably will want some decent documentation first and the analysis tools can help with that :-)

/J\


Comment on Re^2: Analyzing large Perl code base.
Re^3: Analyzing large Perl code base.
by dragonchild (Archbishop) on Apr 15, 2005 at 13:06 UTC
    You don't need to document the dreck you have. You need to document what marketing believes the dreck you have does. The last place you want to look for that is the actual source code.

    Now, I only say this because the OP said (and I paraphrase) "I have a bunch of spaghetti that I can't figure out, so how do I clean it up?" The answer is "Write some tests, then refactor, then write some tests, then refactor, then ..."

    Your testsuite then becomes the basis for your documentation. Obviously, you convert all the ok() calls into English or Swahili or whatever, but it's still the foundation.

      Well, that works until you go to the business and ask, "Where's the spec for feature X?" and they response, "Uh... well, what does it do now?".
        That's perfect - you get to write your own specs! :-)
        • Developer: What's the spec for feature X?
        • Marketing: Uhhh ... well, what does it do now?
        • Developer: It should do foo, bar, and baz.
        • Marketing: Ok, sounds good to me.
        • Developer: Do you mind if I write that up and send it to you for a signature?
        • Marketing: (worried tone) Why would you do that?
        • Developer: Just so that if I screw up, you can hold my feet to the fire.
        • Marketing: (relieved tone) Oh, ok!

        So, you then write whatever you want, Marketing signs off on it, and you go write your test suite, refactor against it, and everyone goes home.

Re^3: Analyzing large Perl code base.
by planetscape (Canon) on Jun 18, 2005 at 06:33 UTC

    If you do decide to go with documentation tools (before, during, or after, and at the least I would pick after), you might wish to start with these:

    Our own castaway pointed me in the direction of podgen, which will jump-start the process of commenting your monolith.

    DoxyFilt* is a filter than allows the well-known Javadoc-like source-to-documentation tool Doxygen to understand Perl. Once you have your source commented, documentation becomes absurdly easy.

    Using Doxygen before and during the analysis process is often helpful for "getting the lay of the land." There is no reason why you need to limit yourself to using doc tools only once. ;-)

    HTH,

    * Update: 2005-12-28 Kudos to both john_oshea and tfrayner for alerting me to the fact that my link above has been rendered usless by the foul creatures known as spammers... I have found what appears to be a good link to obtain DoxyFilt; the most recent version seems to be from August 24, 2005: Doxygen-0.84.tar.gz. Thanks again, guys!

    planetscape

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://448117]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (7)
As of 2014-12-25 23:05 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (163 votes), past polls