One of Perl's major strengths is the speed at which even relatively complex applications can be developed and deployed. However this can be somewhat of a double-edged sword - it is not uncommon for Perl scripts, which may originally have had a simple function, to be only used by a small team or even a single person, to gradually undergo 'feature creep' and grow organically to the point where they are the standard systems for performing a particular task.
Left unchecked, what was a good system for rapid development and prototyping, can bring on situations where 'business critical' (or at least 'business important') applications have not been through full architectural review, detailed design, and QA procedures. Is this a problem? Depends on your point of view. Is this unique to Perl? Of course not, but the Perl language does seem to have a bad reputation in the maintainability stakes. One thing is certain though - if something breaks or a new feature is required, then undoubtedly it will become someone's problem.
In this situation, taking on responsibility for legacy code, which may not have been written in line with current best practices, fixing bugs, upgrading functionality and otherwise maintaining such code is a challenge for any programmer, even when documentation and design notes are available.
Perl Medic, as the title implies, aims to rescue exactly this sort of crisis.
The book starts by looking at ways to establish a program's dependencies, then moves on to testing with a good discussion about automating complete test suites using the various Test:: modules. Following on from this the issue of programming style is raised, with the focus on increasing readability to benefit the next maintainer.
I imagine that Perl Medic will be picked up not only by experienced Perl coders, but by programmers who are relatively new to the Perl language (i.e. those who have just been told "Here's some code, now maintain it!"). This doesn't have to be a barrier - you may hold the opinion that the art of programming itself is the skill, and that specific implementation languages are just syntax. Perl Medic doesn't try to teach Perl from scratch, but does contains numerous pointers to the 'Perl way' of doing things. And of course, the 'not Perl ways', with a good chapter on what is termed 'Cargo Cult' programming, meaning [generally useless] fragments of code which are used (quoting) '...without the author knowing what it does, but because he or she saw someone else doing it and assumed it was right for their purpose'.
Another good example of Scott's writing for non-Perl programmers is the chapter about CPAN. Seasoned Perl coders will use CPAN modules almost without thinking, but to the uninitiated there are valid concerns with using potentially untested and untrusted code. Scott handles these well, then looks at some common tasks (such as parsing HTML, manipulating dates, or processing CGI parameters) which are traditionally re-invented but are much better served by using modules from the CPAN.
The next chapter deals with code analysis techniques for debugging and performance enhancement. This mostly consists of reviews of the appropriate CPAN modules - I would really like to see a bit more detail in a future edition. Following on from this, Scott examines ways to improve reliability and maintainability - parameter validation, version control, and documentation are all discussed, along with a brief look at tieing and overloading.
A common issue faced when maintaining legacy code is that the target version of Perl will usually not be the latest release. Even if the system Perl is up to date the application itself may well have been targeted at an earlier version. Perl Medic helpfully lists the major changes in each Perl release from 5.000 right up to 5.8.3, which is both useful from a 'what can I use' and 'what can't I use' standpoint. It would have been nice to have seen some vendor-specific issues discussed, such as the Red Hat 9 / Perl 5.8.0 localisation (UTF8) problem, but I assume that it would be out of the book's scope to cover all the possible operating systems in detail. However I do feel that the author should have advised the creation of a completely separate Perl installation rather than upgrading the system Perl. Some UNIX variants rely on having a specific Perl version available to control their configuration files, so upgrading to the latest release could have very undesirable effects.
As I was reading 'Perl Medic', it seemed like every other day there was a post discussing the book on one of the Perl mailing lists, or a new review appeared on the web. I've tried to avoid reading these as far as possible (I don't want to just rehash what has already been said), but it is clear that there's quite a buzz about 'Perl Medic' (and Peter Scott's writing in general) in the Perl community, and the overall reaction is very positive.
Well I'm certainly not going to go against this trend. There were a couple of negative points, but on the whole I was very impressed. The pace is kept quite brisk with little that is superfluous, while still managing to make an engaging and enjoyable read. I found 'Perl Medic' to be packed with useful information, and I would have no hesitation in recommending it.
Jon Allen - Perl & Catalyst developer, web designer, and technical manager.
Contact jj@jonallen.info.
Follow me on Twitter at twitter.com/JJ_Perl.