Hello Craigbert, and welcome to the Monastery!
I would like to add two pieces of advice. First, ensure that the existing code has a good test harness; then, as your refactoring progresses, run your new, refactored code under this same harness to verify that it works exactly the same as the original. You will also find it invaluable to place your work under version control (e.g. using git); that way, when a test fails you can easily roll back the latest changes until you identify the change that introduced the problem. If your existing Perl code doesn’t already have a test harness, look at Test::Tutorial, and use the Test::More module which comes with Perl.
Second, remember that related code (data and subroutines) should be grouped together into the same module; but separate modules should be loosely coupled to one another (see the Wikipedia article on Loose coupling.) If your modules are loosely coupled, you will be able to work on refactoring one module without having to worry about the impact of your refactoring on the code in other modules (i.e., the rest of the program). Keep these principles in mind as you design the refactoring, and you will find that the work progresses more logically and “naturally”, and that the final product is more easily maintained and extended.
Hope that helps,
| Athanasius <°(((>< contra mundum | Iustus alius egestas vitae, eros Piratica, |
In reply to Re: How best to break apart a large perl program
by Athanasius
in thread How best to break apart a large perl program
by Craigbert
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |