[forwarded submission from a non-member address -- rjk]
From: Sean Quinlan <[EMAIL PROTECTED]> Date: Thu, 14 Mar 2002 18:02:22 -0500 Subject: RE: [Boston.pm] maintenance of large perl code bases To: <[EMAIL PROTECTED]> At 07:02 AM 3/13/02 -0800, you wrote: >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. That's a very interesting idea. I would also be willing to voulenteer some time for an effort like this, and it fit's nicely with what I'm considering putting together. Now we just need a few more voulenteers, and then find someplace to work with. > 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()). Now that would be nice! Tracing these connections should be possible, but how do you automate drawing the diagram so it's not a maze? I know emacs (not that I know how to) can be configured to jump from call to routine, but I seem to recall there being some effort in getting it set up. > 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. Sean P. Quinlan mailto:[EMAIL PROTECTED] 617-884-4338
