Re: Writing a large application in perl?
by jarich (Curate) on Jun 18, 2002 at 04:30 UTC
|
| [reply] |
|
Excellent list, you forgot one Don't though:
- Don't forget why you're working on the project. Learn as much as you can, make it fun, and hopefully end up with something useful.
Also, to expand on the open source part, consider trying to get other's involved in the project, you never know what it might evolve into :).
| [reply] |
Re: Writing a large application in perl?
by perrin (Chancellor) on Jun 18, 2002 at 01:16 UTC
|
There's been quite a bit of talk here about good patterns to follow (Model-Vew-Controller) and good frameworks to use (OpenInteract, CGI::Application, Apache::PageKit, AxKit). If you really need it to work with CGI, you're more limited in what you can use.
As for code legibility, perltidy gives a good example, and both perlstyle and Tom C's style guide have good advice.
How much OO? It's impossible to give a very useful general answer. Enough to give good abstraction, but not so much that you spend a lot of time thinking about the OO constructs rather than the problem you're trying to solve. | [reply] |
Re: Writing a large application in perl?
by cjf (Parson) on Jun 18, 2002 at 01:38 UTC
|
| [reply] |
Re: Writing a large application in perl?
by dws (Chancellor) on Jun 18, 2002 at 04:38 UTC
|
What im looking for is if anyone has some "do's and don'ts" when using perl for a large product.
Folks have given you good advice above, to which I'll add this: Once a project gets past the point where you can expect to have most of the team members keep the code live in their heads, you'll need a set of diagrams to describe the system. These diagrams can be simple (say, a few UML object diagrams, plus some key sequence diagrams, plus any key state charts). Any more than you can post on the side of a cubicle is too much, in my experience.
Having a set of diagrams makes it a lot easier to bring someone new up to speed, especially with a large code base. Having a few good diagrams also streamlines design sessions. If you're in disagreement, at least you'll know that you're disagreeing about the same thing.
| [reply] |
|
Excellent suggestion.
Having some kind of diagram/flowchart will be a lifesaver a few months down the road. No matter how straightforward it seems when you write it you will forget things later. It will also save someone elses sanity when they jump in to help.
mr greywolf
| [reply] |
Re: Writing a large application in perl?
by jplindstrom (Monsignor) on Jun 18, 2002 at 21:50 UTC
|
With size comes complexity, and you'll have to manage that somehow. One way is to treat the app as a group of smaller scripts, i.e. modules.
Keep the modules separated enough that they don't need to know so much about each other (this is de-coupling). They should only talk to each other using well defined interfaces (this is data hiding). Doing this will make it possble to keep it "small enough" in each module and the overall complexity low by not having to know the big picture everywhere.
Something you actually (hopefully :) did but maybe never thought about when scripting is analysis and design. These have to become more explicit when developing larger applications. You have to take a step back and get an idea of the structure of your application, what subsystems and modules it consists of and how they tie together.
You have to document this somehow and communicate it to other people, maybe fellow programmers, maybe sysadmins, maybe a project leader, maybe yourself six months from now. Pictures are good. Good writing is good.
When the script grows, things that can go wrong add up. Depending on your application, it may need to log things for debugging purposes, and more importantly for outright errors. When things go wrong, abort early, log what happened and notify the programmers (that would be you) by email. This way you'll know when, in your production environment, things didn't work out as planned. This will happen. Promise. Sorry :)
/J
| [reply] |
Re: Writing a large application in perl?
by TGI (Parson) on Jun 18, 2002 at 17:25 UTC
|
Plan a design before you start. What objects will you need? What will each object do? Use pod to document your code as you go along. Plan to throw away at least one design and start over. You will probably get started coding and realize that the design you thought was so nice inherently makes a needed feature very difficult, or some other fatal problem will arise, it's happened to me. Experience will help with this.
TGI says moo
| [reply] |
|
Plan a design before you start.[...]
Plan to throw away at least one design and start over.
Try to keep your design fairly compartmentalized, and
loosely coupled. That way, when you do find a flaw
in your first design, you don't have to throw everything
away: some of the code you've already written will easily
work with your new code. (For instance, if you're always
updating a database the same way, and you keep the database
update code well-separated from everything else, you won't
need to make any changes to it when you realize that your
interface code is hopelessly screwed, trash it, and start
over.)
--
The hell with paco, vote for Erudil!
:wq
| [reply] [d/l] |