Ok, here's the rub:
The stuff that Charles sent is generally things that we've heard before,
and although valid, is often ignored or altogether "poo-pooed" in the crush
of a deadline. When you have one or two people responsible for 30,000 lines
of code, it's often impossible to do anything but keep your head above water
with patches.
A few years ago, I wrote a training manual on teamwork and problem
solving. The latter involved some general guidelines for analyzing problems
and managing their resolution. After a few years, this evolved into
something similar to what is now known as XP, or eXtreme Programming
(http://www.extremeprogramming.org/), which seemed to work quite well, but
was still often bogged-down with dealing with legacy code that needed to be
overhauled to support the new style model.
What I would like to see (and would be happy to volunteer for), would be
for a diverse group of people that includes programmers, admins, and general
support (or even non-techs), to find a worthy organization with these sorts
of problems and to volunteer our services to help them analyze their code
base and create solutions to convert their code to something more
manageable, and in the process, analyze and document the process. I think
this would help us to better understand the unique requirements of such a
process, and to potentially find manageable methods to perform these code
base conversions for any organization.
One big thing in many of these legacy applications is not really that
they are so large, it is the lack of commenting that they use. I have on
occasion spent several hours following code from one file to another just
to figure out what a simple 20-line block of code was trying to do. How do
you solve a problem like this? Many IDEs have code browsers, which would
help in any case, but I honestly don't expect to see them in most Perl
shops. Charles mentions the Block Diagram (program flow diagram) that would
be indispensable for such a problem, unfortunately it doesn't exist for most
legacy apps. Maybe Perl should come with an automated diagrammer? One that
works AND produces some sort of intuitive output. Perhaps it could also
insert comments for namespace/file jumps; for example if a program calls
&foo() and &foo() is in package/object/namespace $Q, than perhaps the
diagrammer could put a comment after it showing the path/filename in which
THIS &foo is located (as opposed to $Y->foo()).
I'm getting off-track here. The point that I am trying to make is that we
need to look at the actual or worst-case, in order to create solutions that
will work for the majority of installations. We can create endless
Ivory-tower solutions to the problem that will be pretty and get great
reviews, but if they aren't workable for the majority of real-world
situations, they won't get used in the real-world.
That's my rant,
Grant M.
