Refactoring Perl applications to give them a rosy future
Archive - Originally posted on "The Horse's Mouth" - 2015-01-11 21:57:32 - Graham EllisI'm doing some contract work at the moment to help sort out a Perl / CGI web solution that's been running well for a number of years, but needs enhancements and a route forward, and for which the original team's no longer available having moved into other full time employment. And it strikes me from looking through the code both how excellently the original work was done in terms of making it followable (quite an acheievement with Perl) and reliable, but also how old fashioned some of the elements are, and how that ties down and makes future developments potentially laborious. In fact I have a huge admiration from the exercise for the folks who did the laborious work to get it where it is today, and my heart bleeds at some of the simplifications and refactorings that I'm doing that cut away their work into somethng that's much shorter in code terms and going to be easier to maintain into the future.
A grand opening - so an examples of what I mean.
• Many of the messages are currently embedded in source - with HTML within Perl prints, giving rise to a complexity of double quotes within double quotes (add backslash protection) and variables within too. Much better (and I'm working on it!) to pull out the messages into separate message files, where the maintainer only needs to know HTML, and using a message system to feed them through. In fact [here] is the source of the message system. Duplication removed, complexity removed, capability added to cascade messages so that they can be amended / edited for individual customer groups or categories.
• Along the same lines, introduction of a unity of utility code for the provision of menu selection items - spotting a commonality that perhaps grew with the system rather than was intended from the start, and adding in as a result a consistency that the users (we hope and expect) will appreciate, as well as making updates simpler and code more followable. The new function looks like this:
sub radio_offer {
my ($question,$fieldname,@pairs) = @_;
my $text = "<p>" . trim(main::message($question)) .": ";
my $k;
for ($k=0; $k<@pairs; $k+=2) {
$text .= $pairs[$k] . "<input type=\"radio\" name=\"$fieldname\" value=\"$pairs[$k+1]\"/> ";
}
$text .= "</p>";
print $text;
}THAT occurs just once and it's called up lots of times like this:
radio_offer("isitmissed","attended","missed","no","attended","yes",
"attended for review","review");
radio_offer("sessiontype","sessiontype","face-to-face","facetoface",
"telephone","telephone", "Skype","skype", "online","online")and there's another version radio_offer_sticky which will recheck boxes for you if a form is re-offered.
• Standardising on far fewer styles, and in places taking out something of a rainbow in favour of a cleaner crisper look. The system already has header and footer functions to give a page to page consistency, but taking these too into standard messages from within the code, and allowing the messages so involved to be changed per site.
• The code is a series of steps through forms spread over a handful of scripts. In areas where the workflow is round and round within that area, combine the scripts into a single script to there's no need to put up an error page and tell the user to click his back button. By working out the possible flows on the board (we've done that), we can step neatly in the right direction from within a single script.
• There's conditional code working out which page is next. I know a lot of time has gone into getting all the && and || conditions right - sometimes several lines of them - but it makes adding things very difficult indeed. Moving on to an error flag system which builds up each "or" element in turn, keeping track if any have gone wrong, makes for followable and updatable code, even if more statements. And by outputting the flag in the event of errors, both user and maintenance programmer will be told why they're being asked to review their previous input and not just that some mandatory box wasn't completed.
If you have code that needs refactoring - it could be a significant job, but don't be frightened and don't feel you need to move away from Perl to a more fashionable language - Perl provides the modernisation tools. Please get in touch with me if you would like to learn Perl of have some more advanced Perl advise. And I'm happy to spend a short time helping make suggestions for your systems too, but at present I've not got capacity for any further jobs line this (in fact if you're a skilled Perl person I know, please get in touch as I might be able to use a couple of days of help!). If you're reading this on the archive - i.e. in March 2015 or later - please do get in touch if you've got a project you need help on, as things might have got quieter!