wyllie at newsof.com
Sat Jan 11 00:41:12 CST 2003
On Fri, 10 Jan 2003, Asim Jalis wrote:
> I have a question. How do people design large programs with Perl?
> Do you start typing code? Or do you spend some time designing it
> on paper?
> If you design it on paper, how do you do it? Do you define the
> functions and what they will do and then flesh this out till you
> have pinned down the whole program? Do you first break the
> program down into modules and then flesh out each module?
> Do you draw diagrams?
> Or is it something completely different?
> Do you use any kind of OO design ideas?
> I am particularly interested in Perl and Perl design experience
> and ideas.
I spend a lot of time thinking about the problems I need to solve
and looking around on the net to see how other people have solved
the same/similar problems. I write most of this information down
on paper with lots of little drawings and schema fragments.
Moving forward, I try and break everything down into smaller parts
so no one piece of project seems terribly overwhelming. I may write
some small programs to test out functionality I may need from
a 3rd party apps and modules. A lot of stuff on CPAN is version
0.01 so you really need to take a careful look at it before you just
blindy assume it's going to do what you want in a way that makes
sense. Once I feel like I have enough pieces and a good
idea of what's going to be easy and hard, I start to draw out
a large diagram that shouws how all the pieces will fit together.
(Literally large, I go down to the local artist supply store and
buy a big pad of 14x17 drawing paper). The big picture diagram
basically becomes the test environment for my requirements doc.
So each feature/function I need my app to do can be traced through
the big diagram.
For example, the project I'm working on right now is a community
based website. It has three layers:
+ database interface/logic (the "object manager")
+ the database itself
In the first layer I need to worry about all the forms, site
content, the webserver and server modules.
The second layer is like a relay between the presentation layer
and the database. Here I have to make decisions about what kinds
of databases I would like to interact with (RMDB, LDAP, BDB, flat files?),
and things like, user/group permissions and ownership, how are we going
to deal with the search engine, etc. I kind of stole the ideas for
this layer from Corba (which I have never programmed in). The idea
was to create XML objects for all the user content, serialize them,
and do stuff with them (like store/retrieve them, parse them into the
search engine, apply different style sheets to them (sort of like XSLT).
The database has it's own set of problems and design issues (especially
around performance and admin things like backups/replication).
All these things are in the picture. Then I look at my requirements
and try to figure out how the data (or whatever) will move through
this system. (the drawing is in pencil - pick up a big eraser down
at the art supply store).
Finally once I get all the stuff figured out, I start piecing it
together, trying to reuse code as much as possible, try not
to be scared to throw stuff away when it gets to complicated or is
just plain broken and lots of refactoring (and not enough testing).
The core of the whole project is the ObjectManager it tells the
Forms what data to get, and knows how to talk to all of the
Storage/Viewing/SearchEngine or where ever else the data needs to
go. So there are a number of APIs, and some OO things going on,
and maybe some Klingon code way deep down...
Our final (well mostly final) product probaly has 80,000 line of perl
code ( I think that's the number someone came up with). We continually
upgrade, refactor and learn new things as we move forward. You can
see the site at http://www.acscsn.org - The Cancer Survivors Network.
Not sure if that's the kind of stuff you were looking for or not, but
maybe it's helpful somehow.
> spug-list mailing list
> spug-list at mail.pm.org
More information about the spug-list