|P is for Practical|
Re: A use strict confession, with real questions. (Perl scriptors and Perl programmers)by Discipulus (Abbot)
|on Jun 05, 2015 at 09:18 UTC||Need Help??|
ok perlidiot123 welcome (even if you are here before me..), you got precious answers yet. I'm not a professional programmer and i'm somehow in your same situation.
From what i understand you have an heritage codebase, with a lot of scripts, a lot of dependencies, a lot of underlined design grown up trought the years. Probably you also have a lot of inter system communication (databases, remote data..). And all pieces of the codebas interact indipendently with such data. This is production code involving money and the safety of your job. It is critical.
Your confession to not using strict seems to me the less important issue.
In fact your (and mine too, dont feel is a critic to you..) software was developped without a strategy, without the foundamental habits of the professional programming.
Somehow the cause of this is Perl itself. Is a side effect of his power: the job can be done so quickly that you was tempetd to get the job done, without a long term strategy. I have done this error many many times. And as always refactoring is a pain, worst and riskier than write solid code from scratch.
As stated before by wiser monks, test is the crucial word. But we are in a bad situation because standalone scripts with a lot of globals are not testable, or better said, not easily testable. You can write tests using IPC::Run or similar.. good luck!
So before doing something on your codebase, my best suggestion is to learn well how professional code is written. I'm around such theme since months. I think the right approach, the habit, tell the difference between a Perl scriptor (as i m) and a Perl programmer.
The code must be contained in modules! Is the only thing i found restrictive in Perl: the .pm extension needed by modules during lookup. Beeing basically a collection of subroutines the module force you on the right path: you export behaviours and possibly no variables: data will be accessible through sub call. You won: your application script become a skelatal glue of behaviours contained in a module.. a module you can run tests against.
Extremistically: consider shifting your point of view: you imagine some behaviour for your future software, then you write tests that restrict, define, delimit, test your needed behaviour with possibly edge cases and errors too before writing a single line of the wanted resulting code. Then in a heaven world you have also the time to write down the pod documentation in the module before even declaring a single variable. This approch saves your weekends, that are definetively the only reason to write software.
Exploring this subject i collected some usefull links: the basic doc
writing solid cpan modules
A brief question about testing/best practices
Creating (and Maintaining) Perl Modules
Corion's answer in thread about module facilities
namespace and modules
require "shared.pl" with use strict;
Also very interesting is the Modulino idea explained in mastering perl by brian d foy.
So if you really want to upgrade your software you'll face a surgeon job: you need to dissect the production code organism, extrapolating behaviours. Probably you can easily start from the required .pl files transforming them in modules with tests and docs. Probably is wiser to have configuration stuffs in separate files adding the ability to run against a dev environment or against a production one with zero effort.
There are no rules, there are no thumbs..
Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.