Clear questions and runnable code
get the best and fastest answer
Re: Refactoring a large scriptby Limbic~Region (Chancellor)
|on Jan 18, 2007 at 17:52 UTC||Need Help??|
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.
RequirementsYou 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.
TestsUsing 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.
ClarityConsider 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 ControlBefore 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 OrganizationBreak 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 PracticesDamian 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.
ProfilingAt 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.
BenchmarkingYou 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.
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.
Cheers - L~R