Requirements

You wrote this script for a reason, have you bothered to document what that is? Start with the big picture and refine your requirements. For instance, I need a way to visualize the email I receive might be a big picture requirement where as The report must be able to be sorted in ascending or descending order using column "subject", "sender", or "date" would be a lower level detail.

Tests

Using your requirements outlined above, develop a test suite that validates your code meets all your requirements as well as ensuring you do not break anything. Since you will be backing into this process, I highly recommend you perform code coverage testing. If you determine that after you have written a test for every requirement you are thinking of but still are only testing 30% of your code, you need to reconsider why that code was written in the first place.

Clarity

Consider using perltidy on your code to make sure it is readable. Additionally, you may want to adapt your own style. In a nutshell - you want to make sure you are consistent, use meaningful names, and have done a good job commenting and documenting your existing code.

Editing and Source Control

Before you change a single line of code, make sure you are using source control (subversion for instance). Additionally, using an editor that has plug-ins for templating control structures and syntax highlighting (never foolproof with perl) will go a long way in saving you time.

Abstraction and Organization

Break your code up into small digestible chunks and arrange it in some logical order. Code is easier to read and understand if it is short, contained, and performs a single function. Group code together that performs similar functions and turn it into a sub. Look for code that has been copied and pasted and turn it into a sub. Better yet, follow Elian's rules for code re-use.

Use Best Practices

Damian Conway has written Perl Best Practices but you can also use Perl::Critic to help you automatically find issues with your code. Keep in mind that best practices are rules of thumb and you need to know when it is ok to ignore them, but this will go along way in keeping your code maintainable and secure.

Profiling

At this point, your old code should be looking pretty good. You may not even need to worry about performance at this point but if you do, you should not guess where the problem is. You need to profile your code (search CPAN) to identify where your bottlenecks are.

Benchmarking

You will also need to Benchmark any changes you make to verify that your new code is any better than your old code. You will want to verify that the data you use is representative of what your program will actually be using since different algorithms behave differently under different circumstances.

Help!

The perl community is large and diverse.

• PerlMonks
• Perl Mongers
• Use Perl
• LiveJournal
• Internet Relay Chat (IRC) #perl, #perlhelp on various networks
• Various different mailing lists - try google groups
• Yet Another Perl Conference
• OpenSource Convention
• The CPAN
• Articles, Columns, Magazines, Presentations (see below)
• perl.com
• The Perl Journal
• The Perl Review
• Randal "merlyn" Schwartz's Columns
• Mark Jason Dominus' Perl Paraphernalia
• Perl at Oreilly

Be sure to read their respective FAQs and practice learning how to ask a question.

What Else?

I have only begun to highlight the areas you need to be concerned with and may have left a few out all together. Spend time researching each area. I would recommend "The Pragmatic Programmer" and "Code Complete". You will find that the maintenance of this program is never complete and that is a good thing. The only finished program is an obsolete one.