-sam

Too bad the code's original author didn't read that book! It seems at this point, it's too late. :(

To the OP, I'm afraid you might have to brute-force this one. Think of it as "job security", if that helps any. I feel for ya - see my sig.

---
It's all fine and dandy until someone has to look at the code.

It's never too late for Perl Medic! It's a book about how to fix bad old code.

-sam

Perl Medic to the rescue! Go buy it right now - it's exactly what you need.

Seconded.

I'd also recommend Working Effectively with Legacy Code.

The recent Strategies for maintenance of horrible code? might also be of interest.

I've unfortunately been involved in similar situations a few too many times

The best advice I can give is to keep the two systems running in parallel for testing, and get all stakeholders to sign off on their parts before the final migration.

I don't know what the motivation is for switching, and what your schedule is like, but depending on just how bad the things are you're dealing with, it might be worth trying to upgrade the FreeBSD box (in terms of hardware) to buy yourself a little more time -- if you have to move to a new system, just copy the binaries directly.

For the eventual Solaris migration, I'd also suggest trying to mirror the modules versions from the old system as closely as possible. (if you've been using CPAN for your installs, you should have an install log) You don't want to mess with the perl that's installed by Solaris, or you can potentially break some of their management scripts. (at least you would under Solaris 8 and 9, I've never played w/ 10).

Oh -- and when your boss insists that you make a full tape backup of the system before you move the new one online -- remind him that the old stuff is still online (maybe under a different IP address), so you don't turn a 5 minute outage into a multi-hour outage. (there were reasons we were upgrading ... like only having a 10BT interface)

Once you get it migrated over, then I'll second the recommendation of looking at Perl Medic, as you probably have a deadline that keeps you from following the suggestion before.

And try to keep the old system up for as long as possible -- Finding out that it never worked on the old system can keep you from wasting a week and/or having to deal with a manager chewing you out for something that's not your fault.

Update: this was on my mind because I've done these sorts of upgrades more times than I'd like (5? 6? ... I think I've managed to block a few out) ... so let's look at the specific issues:

There are approximately 300 scripts, spread across several directories, and none of the scripts contains either of the lines: use strict; use warnings;

Unless you get to set the schedule, don't worry about this. Find someone willing to sign off on each script, and don't try to fit the scripts now. Odds are, they're broken in some way, but they've been that way since before you got them -- you can only hope that they don't break worse when the version of perl and any used modules change.

Code has been replicated for each operational area, and each common script has been modified to support the specific aspects of its corresponding functional area

You can modularize it after the move. Unless you want this move to take a year, treat it like the last one.

Subroutines that have been repeatly cut and pasted, and then further modified

Again, don't worry about this one now -- treat it like the others.

Paths and filenames have been hardcoded

Okay, this one's a problem. You really need to get some symlinks in to make the old pathing still translate. If you can't get your sysadmin to fix it, get them to sign off on the fact they're refusing to make the change. You do not want to screw with these things if you don't have to. If the sysadmins don't cooperate, see the next one.

Some system/backtick calls will need need to tailored to Solaris10

This one's the only one that must be dealt with in some way. To some level, if you know what programs they're calling, and it's just a few executables, but a lot of perl scripts, you can adjust the path, and place a few wrappers in there to take the old calling syntax and align it with the solaris usage. (or you can compile the GNU, or whatever versions -- one of the uses of the FreeBSD ports collection)

If there are relatively few perl scripts compared to the number of external commands being called, you're SOL -- the following might help: find ./ -type f | xargs egrep '`|\bexec\b|\bsystem\b' | grep ':' | cut -d: -f1 | uniq | xargs vi (insert your favorite editor for 'vi')

No unit tests are available

Treat it like the first few -- get someone else to sign off on it. Unless you're luckier than I've been, management will be breathing down your neck, and you'll not be able to capture all of the necessary business logic before the move -- deal with it afterwards.

Step one, check all of the code into a reliable version control system. Accept nothing less capable than Subversion (darcs, git, bzr, svk, and p4 should all be fine). If you don't know how to use a revision control system, learn.

Step two, run Perl::Tidy over all of the code per your preferred rules. Check in the new versions. Make sure they still compile with perl -c and check any perltidy.ERR files.

Step three, Perl Medic should have arrived by now. (Order it as step zero. Do not skip this step; it is an excellent book written well by a very capable programmer and everyone should read it.) Follow its steps.

One thing i neglected to mention was that the Solaris10 environment change requires that I find all references to /usr/local/www/... and change them to /etc/www/...

This is required because I do not have *write* access to the /usr/local tree -- its a Solaris "jail" thing.

The net result here is that I have to find every string or concatenation thereof that evaluates to /usr/local/www/... and then change them to the new path.

Ugh -- I suspect the potential for breakage is high.

Where do you want *them* to go today?

Once you copy the tree into the new environment (maintaining a copy of the original of course), you can run

find . -name '*.pl' -print0 | xargs -0 perl -pi'.bak' -e 's=/usr/local
+/www/=/etc/www/=g'
[download]

This is one of the few parts of the job where having little or nothing in modules makes your job a little easier.

If you find breakage from this, you can go back and do it again with a more refined substitute, or do further such substitutes. It's a case of Perl helping Perl.

As others have said, Perl Medic is good. It has good, realisitc advice on strategies, as well as providing tools to help you do the work. Our sympathies are with you.

use strict;
use warnings;
[download]

Depending on how much is hard coded by way of file names and so on, you may want to consider adding a configuration file using something like Config::Simple. In fact I would try that before I even try to move off the BSD machine.

As for the future? Well maybe tests wouldbe a good idea. But also a move to a more robust module or OO based coding paradigm with better documentation and re-usability would be nice! But in the end? Well I am sure you can read all the sage advice on the monsatery without asking too much!

jdtoronto

• Port everything over to a test box so that you can make changes without worrying about the effects on other scripts as each one goes "live"
• Write a script that will go through each script on the text box and add the 2 lines "use strict;" and "use warnings;" because as we all know, that makes for cleaner (and more portable code).
• The next thing I would suggest is to see what you can port into modules. You said that there were a lot of subroutines that were just copied and pasted with slight mods. If there can be turned into reusable code, that would take care of a lot of code cleanup.
• Harping on reusable code, see what's out there (in CPAN) that may already perform the functions that the scripts do (and it may work more efficiently). You may have to rewrite a few scripts to work with the CPAN modules, but all in all, it sounds like that's the least of your troubles.

Good luck

Eric

Some of the tools/suggestions here may also help:

DoxyFilt (Doxygen for Perl) offsite
Analyzing large Perl code base.
Becoming familiar with a too-big codebase?

Good luck!