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:

  1. 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.
  2. 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.

In reply to Re^2: Developing larger applications. by adrianh
in thread Developing larger applications. by karmacide

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.