in reply to
Refactoring a large script
To end up with a product that you are happy with and that is easy to maintain in the future, you are going to have to do a lot of work. Since it seems you are eager to learn, you won't mind. Please keep in mind I am writing this on my lunch break so I am likely going to miss a few things. I am sure others will expand on what I have been too frugal with and fill in the gaps for what I missed outright.
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.
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.
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
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.
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.
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.
The perl community is large and diverse.
Be sure to read their respective FAQs and practice learning how to ask a question.
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.