Smoothhound, you potentially have a big task on your hands.
If you are not using a version control system, start using one. Check in the current version of all modules, and use this for progress. Even if you are working solo, it's still worth doing.
If this were me, I would start with a review of code quality in general. Do the modules use strict and warnings? If the answer is no, this would provide a starting point. Aim to get all the modules passing strict and not emitting warnings. See Thoughts on revisiting old code for my musings on this subject.
This may be a question of looking at documentation rather than code. In the worst case, there may be no documentation, not even comments in the code; if this is the case, write a POD section for each module describing its interface.
Just because a module is not going onto CPAN is no reason not to follow the standard guidelines for delivering a module. Most of the modules you are looking at were probably not generated with h2xs and friends (ExtUtils::ModuleMaker, Module::Starter). Make kits for each module or collection of modules.
The CPAN style install mechanism has a provision for including unit tests. Write a suite of tests for each module kit.
--
I'm Not Just Another Perl Hacker
In reply to Re: Private module organisation
by rinceWind
in thread Private module organisation
by Smoothhound
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |