To be fair, I think you probably will want some decent documentation first and the analysis tools can help with that :-)
/J\
| [reply] |
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.
| [reply] |
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?".
| [reply] |
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!
| [reply] |
