Re: Developing larger applications.

One perl-specific thing I find with big jobs is that because perl coding styles can vary, it can be very useful to have a general style guide for the project. Here is an example to get you started that I've been accumulating over several years specifically for very large perl code trees.

In general, comment more and use simpler code than you might if it's a small application.

Some big projects take a while before enough pieces come together to show a snazzy demo system. If you go with CVS, perhaps something ( blatant promo :) to keep management comfortable work is actually moving forwards.

Test lots, and test first if you can, but if you get REALLY stuck, and can't think of a good way to test something, don't let it stop you or divert weeks rigging complicated emulation systems, at least not at first. Consider a small example or demo script which, while not testing formally, will allow you to run some tests runs on a particular subsystem, and just debug it using the perl debugger.

If you go the mod_perl route, make as many pieces testable WITHOUT having to run it inside mod_perl as possible. perl -d test_script.pl is an easy way to find bugs. Doing the same on a mod_perl module is often harder without spending large amounts of time writing complicated emulation code.

Also, write down and write up. By this I mean, write a sufficiently thorough framework to handle the entire system early, and if you find some task or subsystem that can be completely seperated from the rest of the system, stop and get that written and completed first.

You'll have a nice big framework for everything to fit at the top, and a toolkit of standalone modules/widgets at the bottom, and work your way towards the centre.

Comment on Re: Developing larger applications.

Replies are listed 'Best First'.
Re^2: Developing larger applications. by adrianh (Chancellor) on Jun 06, 2004 at 18:32 UTC
In general, comment more and use simpler code than you might if it's a small application. Seconded. Although I would personally emphasise simple code over more comments. I often find comments get in the way of simplifying the code. If I write a bit of opaque code and my first response is to write a comment to explain it then the code stays complicated. Instead I find it a useful mental exercise to ask myself 'Is there any way I can make this code easier to understand?' whenever I am tempted to write a comment. I usually find that there is and the comment proves unnecessary. If you go the mod_perl route, make as many pieces testable WITHOUT having to run it inside mod_perl as possible. Not that I disagree with this excellent advice but... Doing the same on a mod_perl module is often harder without spending large amounts of time writing complicated emulation code. ... Apache::Test has made testing mod_perl code a lot easier recently. Also, write down and write up. By this I mean, write a sufficiently thorough framework to handle the entire system early, and if you find some task or subsystem that can be completely separated from the rest of the system, stop and get that written and completed first. Personally I have moved away from trying to design and build frameworks up-front. For two reasons: I find that that my initial design decisions / assumptions prove to be incorrect in the long term. Requirements change. Assumptions prove incorrect. Complex areas turn out to be simple. Simple areas turn out to be complex. If you do too much of the framework design up front you end up throwing it away or shoe-horning code into it. Working with a more complex framework early in development can actually slow you down because you don't need the extra bells-n-whistles until later in the project. Instead I incrementally build the framework as I go along. That way I can keep it flexible in the face of changing requirements, and I don't have to carry any extra infrastructure weight until I actually need it. It needs more discipline to keep everything refactored as you go along, but I've found it a more effective technique myself.	[reply]

Replies are listed 'Best First'.

Re^2: Developing larger applications.
by adrianh (Chancellor) on Jun 06, 2004 at 18:32 UTC

In general, comment more and use simpler code than you might if it's a small application.

Seconded. Although I would personally emphasise simple code over more comments.

I often find comments get in the way of simplifying the code. If I write a bit of opaque code and my first response is to write a comment to explain it then the code stays complicated.

Instead I find it a useful mental exercise to ask myself 'Is there any way I can make this code easier to understand?' whenever I am tempted to write a comment. I usually find that there is and the comment proves unnecessary.

If you go the mod_perl route, make as many pieces testable WITHOUT having to run it inside mod_perl as possible.

Not that I disagree with this excellent advice but...

Doing the same on a mod_perl module is often harder without spending large amounts of time writing complicated emulation code.

... Apache::Test has made testing mod_perl code a lot easier recently.

Also, write down and write up. By this I mean, write a sufficiently thorough framework to handle the entire system early, and if you find some task or subsystem that can be completely separated from the rest of the system, stop and get that written and completed first.

Personally I have moved away from trying to design and build frameworks up-front. For two reasons:

I find that that my initial design decisions / assumptions prove to be incorrect in the long term. Requirements change. Assumptions prove incorrect. Complex areas turn out to be simple. Simple areas turn out to be complex. If you do too much of the framework design up front you end up throwing it away or shoe-horning code into it.
Working with a more complex framework early in development can actually slow you down because you don't need the extra bells-n-whistles until later in the project.

Instead I incrementally build the framework as I go along. That way I can keep it flexible in the face of changing requirements, and I don't have to carry any extra infrastructure weight until I actually need it.

It needs more discipline to keep everything refactored as you go along, but I've found it a more effective technique myself.

[reply]