Customer Reviews

Perl Medic: Transforming Legacy Code

5 star:		(4)
4 star:		(2)
3 star:		(1)
2 star:		(0)
1 star:		(0)

 

 

You can learn a lot from books (or so it seems), but you can't learn a feel for the language. I had read all of the O'Reily Perl books and found myself in charge of a large Perl project writing new code. I hired on a real Perl guru and he taught me a ton, in person, about how to write Perl as Perl and do it well. What amazes me about Perl Medic is how much of what the Perl guru taught me is in this book. It's as if I had the man by my side again.

On it's face that makes it sound like you should pick up the book immediately. And for someone who is serious about Perl I think you should get this book. But there are still some faults. It could be a little better organized. And some of the common problems, like CGI scripts having embedded HTML, could be given more prominence and the text templating alternative given some more space. I looked in the tiny index for HTML::Template and found only two references, both of which were pretty short.

In what is probably both a curse and a blessing the book is not only about fixing legacy code. The majority of the book is about becoming a better Perl programmer and writing Perl as Perl. There are a few chapters and the beginning and end that are specifically about working with legacy code, but the majority of the book is practical insights into Perl coding styles using code fragments with effective exposition.

Small problems aside. This unique book is fun to read and is packed with valuable insights if you spend the time to look. The author obviously knows a lot about Perl and understands how to convey that knowledge to the reader effectively. If you are looking to maintain some Perl, or if you have hit a plateau in your understanding of Perl and you need a push to get to a higher level this book is for you.

A quote on the front cover of this book says "if you code in Perl then you need to read this book". That's a pretty bold claim to make. It made me think of the hyperbole on covers of books that claim to teach you to program in Perl in just a few days. But this book is published by Addison Wesley, who are a well respected technical publisher of technical books and the quote is from Adam Turoff who certainly knows what he's talking about when it comes to Perl programming. So in this case the claim isn't hyperbole. The book really is one that I want every Perl programmer to read.

Perl gets a lot of bad press from people who claim that it encourages people to write unreadable code. Whilst there's certainly a lot of very bad Perl code out there I think that's more a sign that it's used by a lot of people who don't know how to program than a reflection on the language itself. And that's where this book comes in. It assumes that you are familiar with the syntax of Perl but that you've never really been shown how to use it effectively. Which is a situation that many Perl programmers find themselves in.

Perl Medic is actually targetted at people who have to maintain older Perl code written by someone else, but I think that the information it contains is just as useful to anyone coding in Perl. Peter Scott has a lot of experience in writing Perl and in training other people to write Perl and the distillation of that experience and knowledge into these 300-odd pages mean that there are few Perl programmers who won't pick up something useful from this book.

The main emphasis in the book is on increasing the maintainability of code. The techniques are wide-ranging. I particularly enjoyed the examples of refactoring programs and the coverage of using modules from CPAN. Two other very good sections are the one on antipatterns in chapter 4 and the one on cargo cult programming in chapter 6. Together these sections give a programmer a number of easy to recognise quick wins when improving existing code and a checklist of things not to do when writing new code.

There are a couple of niggles. I've already mentioned that I think the book has been slightly mis-targetted and that it should have been aimed at anyone writing Perl code. The other problem that I had was that the medic analogy that runs through the book gets a bit strained at times. But these are only minor and they shouldn't prevent you from adding this book to your library.

In fact, all in all, the quote on the front cover is pretty accurate.

While the "medic" metaphor recurs throughout the book, most of the material isn't directly related to repairing old code. Instead, this is a collection of best practices for new code. (The author recommends rewriting existing code if at all possible.) It ends up resembling another excellent Perl title, Joseph Hall's Effective Perl Programming. Good company to keep. Perl Medic has the advantage of being newer, and of covering a bit more material. The writing style is very easy to read, and the order of presentation works well. An excellent title for any intermediate-level Perl programmer.

The book didn't really give me any insight in how to transform legacy code to modern oop. The examples were ok but considering I bought this based on other reviews I figured it was great. It's not. Of the 30,000 lines of code I inherited in my first perl script, I may have refered to this book one time. Don't expect much help in modernizing, just seems to focus of figuring out bad code not refactoring. Maybe I'll use it as I update other scripts but for now it sits well under perl by example and camel 2nd ed.

When Perl Medic came out, we received a review copy. It was the first review book we got, and I was pretty excited. I took it to (of all places) the gym with me, and read it while I ran. A lot of Perl People were raving about how it was the awesomest book in a long time, and I just couldn't get that excited about it. Despite that, I find myself recommending it to more and more fellow programmers.Here are the things that I find especially useful in the book:

Tests

I am all for testing. I like testing. Testing helps me code better. Testing helps me figure out what badly documented features should do, and helps me notice that my patches are going to break in production. It's just the right thing to do. When reading, I thought the coverage of testing was a too long, but that was because I was already at home with it. Really, it's the right length for someone who's not already testing, and Peter Scott should be applauded for writing one of the first Perl books to really explain and encourage testing. Moreover, he stays true to the book's "for maintenance programmers" nature and talks about the troubles with writing tests for code you didn't write, including testing traditionally hard to test things like CGI scripts.

perldelta

The book walks through historical versions of perl from version 4 (!) to 5.8.3. The authors tells you what changed, and what you should probably do if you upgrade the platform your old Perl code is running on. (Moving to 5.6? Now you can use C<our>. Moving to 5.8? Restricted hashes!)

Cargo Cult Perl

The author devotes almost a whole chapter to pointing out stupid things that people write because they don't really know what they're doing. open without checking the return, symbolic references, three part for, and (argh!) return undef.

I hear Dominus is working on a book on this topic. Until then, this should help people write code that will be less of a pain to maintain.

*other stuff*

Perl Medic offers a concise explanation of scoping and variable types. It's no Coping with Scoping, but it's quite clear and covers C<our>. While a lot of Perl Medic is really for experienced folks maintaining old code, this section is something every new Perl hacker should read.

There's a nice section on figuring out WTF existing code /does/, suggesting modules to benchmark, profile, deobfuscate, and otherwise dissect the horrible code you're handed.

In the appendices, there's a few pages on "How to Ask Questions that Get Answered." There exist many of these guides, but I don't care. If every technical book spent two or three pages on this, it would be a blessing. Somebody who knows how to ask a question is going to get help, and is going to quickly be received into the community where he asks it.

*the down side*

I guess the biggest down side for me was that I just didn't learn many new things from this book. A number of things were well stated, and I recognized that this book would be useful for many people, but for the most part I didn't have many "A-ha!" moments.

There's a section on "how to use the CPAN," and I felt it was out of place. This might be, though, because I find the idea of Perl without CPAN (for non-tiny projects) to be insane. I guess there must be people who do have to deal with "anti-CPAN policies," though.

This book is definitely a good buy for anybody who's going to be taking over someone else's code, especially code that's old or just lousy. (Even if it's good code, this book can help.) Whenever I leave my job, I will make sure they pick up a copy for the new guy.

Like author Peter Scott's previous book (co-written with Ed Wright), Perl Debugged, Perl Medic is rather inaccurately titled. Both books are collections of advice and tips on best practices and idioms in Perl, like Effective Perl Programming and Perl Best Practices. You can think of Perl Medic as a sequel to Perl Debugged. You definitely don't need to have read the former, but if you have, you should have a good idea about the format and contents you can expect here.

There is more advice on code style, low-level stuff like brace indentation and choosing decent variable names. Additionally, tracing, profiling, benchmarking and logging are again introduced. Some of this is admittedly rather reminiscent of what appeared in Perl Debugged. Happily, also present is the clear writing, which is informal without ever talking down to the reader.

Perl Medic, however, has a more agile flavour than Perl Debugged. Again, there is a chapter on unit testing, but it's much more fleshed out in this book, featuring far more modules, and providing an entire Test Driven Development example of a bounds-checked array.

Also, some refactorings are introduced, such as inlining temporary variables and extracting subroutines. The final chapter of the book is a refactoring example on some ancient Perl 4 cgi code, that pulls together most of the themes of the book.

There's also an in-depth discussion of what the strict and warnings pragmas entail, beyond that provided by most books. Also worthy of note is the chapter on 'cargo cult' Perl, where the author's pet peeves about non-idiomatic Perl code are explored, from practices which are merely pointless to the downright wrong.

Much of this material is general good practice. However, there are some chapters that help to justify the 'legacy code' approach. Chapter 7 provides a potted history of the different versions of Perl from Perl 4 onwards, and how to spot which version a program was targetted at. There is some mention of legacy code in the unit testing chapter, but not much.

In general, I think a lot of the suggestions will be obvious to anyone with experience with Perl, or experience with another modern programming language: use new modules from CPAN where you can, use lexically scoped (my) variables and localise global access and, of course, turn on strict and warnings. Overall, I wasn't much convinced with the 'legacy code' aspect of the book and the strained medical metaphor renders many of the chapter names nonsensical.

Another slight problem I had is that, like Perl Debugged, there can be a lack of flow between (and sometimes within) chapters. Chapter 10, nominally about maintainability, starts with assertions and Eiffel-style contract programming, and then goes onto logging, tieing, overloading, POD and version control integration. It's hard to see this as a cohesive whole.

If you're looking for a book on dealing with legacy code, Michael Feathers' Working Effectively with Legacy Code provides more bang for your buck -- although it's not Perl-specific (in fact, I'm pretty sure there's no Perl code in it at all). However, if you're a budding agilist looking for Perl-based examples of refactoring and TDD, then this is a good choice. Less experienced Perl programmers should definitely consider this, especially alongside Perl Debugged, as it provides both a good grounding in best practices, and more advanced development skills such as profiling and code coverage.

I wish I read this book earlier...
In fact it's my only regret about this book...

This book is an absolute "must have" for every Perl beginner.
Teaching how to program safely, and to maintain/debug/clean Perl code is not an easy goal, but the author
(who is obviously someone who loves and knows Perl)
manages to do it in a simple and pragmatic style.

A lots of subject are covered too many to mention here
(you HAVE to read this book anyway ;-) )
but I'd like to point the chapter about "cargo cult programming" which will be highly useful to beginners to my mind
(So sad the cargo cult constructor isn't described too (you know the one using : my $class = ref $proto || $proto; ))

While oriented to the beginners (IMHO), the experienced Perl coder will also probably find some useful tricks.
(Useful modules, uncommon options or other pieces of code that increase your productivity...)

In short this book is pure "Perl Packaged Experience", save you hours of trial&error frustration and buy this book, you won't regret it...