Monday, July 23, 2007

OSCON: Taming Legacy Perl

I'm here listen to Peter Scott talking about legacy Perl because of the just over two hundred thousand lines of Perl code sitting in my CVS archive, a lot of which I wrote over five years ago now, when I really wasn't as good at this stuff than I am now. I was actually at Peter's talk during the OSCON in 2005 and I talked about this myself at the London Perl Workshop in 2004, so I'm really interested to see how his talk has evolved into a full-blown tutorial.


Peter Scott talking about Taming Legacy Perl

Update: So we're twenty five minutes into the conference and we've just had the first crash of the wireless network, I was sort of expecting it to last a little bit longer, it's not as if O'Reilly haven't done this before?

Update: Peter is talking about optimisation and advising us to try and figure out, not just what a piece of legacy code was intended to do, but also what it was optimised for; maintainability, performance, brevity or even job security. This is pretty good advice, although my own experience is that most people write Perl which isn't optimised for anything in particular except to "just work".

Update: Interestingly this is the first I've heard that Makefile.PL files and the ExtUtils::MakeMaker module are being deprecated (and removed from the Perl core?) from Perl 5.9.4. That's going to hurt...
ExtUtils::MakeMaker has been a de-facto standard for the common distribution of Perl modules; Module::Build is expected to supersede ExtUtils::MakeMaker in some time (part of the Perl core as of 5.9.4). The transition takes place slowly, as the converting process manually achieved is yet an uncommon practice. The Module::Build::Convert Makefile.PL parser is intended to ease the transition process.
Update: From optimisation he's moved on to talk about testing and the many test harness modules available in Perl. The simplest, that you'd actually want to use, is of course Test::More which is built on top of Test::Simple which you probably wouldn't want to use yourself. I'm actually a bit surprised there are people writing this stuff down, which scarily implies that they don't already use one of the numerous unit test modules. A couple of other useful test modules he's talking about are; Test::NoWarnings and Test::MockObject.

Update: Time for morning coffee, back after these short messages...

Update: I'm actually a bit disappointed, while Peter is a good enough speaker and the material is solid enough, he's been talking for an hour and a half and he hasn't said anything I don't already know. I'm starting to wonder whether I should stop going to the Perl track here at OSCON and branch out and do other stuff, either that, or actually organise myself a couple of months earlier and submit some tutorial ideas. Of course with no Damian Conway or Randal Schwartz this year you have to wonder, as a Perl conference at least, whether OSCON has jumped the shark?

Update: He's finally moving on from testing to talk about refactoring, in fact he's talking about rewriting. Someone sitting right up front has asked him about accumulated domain knowledge, he's making the exact same point I made in my own talk at the LPW. Looks like Scott and I totally disagree here, back in 2004 I said something along these lines...
The first thing a developer wants to do when they start on a new project which has an extensive established code base is to rewrite the legacy code, or at the very least re-factor the code. However your project’s legacy code encapsulates knowledge, every bug fix, every bright idea by the programmers who have worked on the project before you is in there. Do you really want to have to rewrite all that code, and have all those bright ideas again? - Alasdair Allan
I'd still argue that your code base is the fossil record of your organisation and the worst possible mistake you can make is to try and re-implement your existing code base from scratch. If you have to refactor your code, but never rewrite.

Update: Peter is talking about cargo cult programming, but again I'm going to have to disagree. He's trying to be too clever, some of the examples he's giving of cargo cult Perl aren't, they might be that way for a reason. Sometimes optimising the Perl for readability, maintainability or elegance isn't the way to go. Sometimes you're looking at a decade of corner cases and bug fixes. You really have to be careful about "fixing" that sort of stuff.

Update: So now we're covering DBI placeholders, I'm bemused. I rarely have to do heavy weight database work, and I'd view my knowledge of DBI as only fairly sparse, and even I know about place holders. So why is he covering this?

Update: Okay, now he's talking about global versus local variables. Erm...?

Update: ...and we're done. I must admit, Peter's presentation was fairly decent, but as he got further into his subject I started disagreeing with a lot of the stuff he was recommending. I guess it's a matter of style, but especially with his insistence that rewriting code is a good idea, I think he's giving bad advice on some subjects. Time for lunch...

Update: Brad was also blogging this tutorial.

3 comments:

  1. I'm not at OSCON because I'm double-booked. sage-au.org.au announces their annual conference dates about three months before OSCON does, and I was already commited to SAGE-AU before finding out that OSCON was the same week, and I can't be at two places at once, and first one wins. So here I am, halfway around the world, the same week that OSCON is happening in my own city. Odd.

    ReplyDelete
  2. Come to my "Managing Technical Debt" talk on Wednesday, first thing after keynotes. I think there'll be good stuff for handling legacy codebases, although not from a code point of view

    ReplyDelete
  3. I was actually already intending to go to that Andy!

    ReplyDelete