Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

Re: Starting a Large Project

by belg4mit (Prior)
on Feb 12, 2002 at 00:59 UTC ( #144749=note: print w/ replies, xml ) Need Help??


in reply to Starting a Large Project

One approach is to write a skeleton man page, this way you can define exactly what you wish to accomplish. To be honest though I usually simply start by implementing the core algorythym or interesting features of the project and extending and patching holes until I have a functional unit. I do come close to practicing what I preach though, usually before writing any code or after having written very little the idea will have been gnawing at me for at least a few days and I will of thought of features and possible implementations for various portions of the code. I reccommend keeping lots of paper on hand at all times.

--
perl -pe "s/\b;([st])/'\1/mg"


Comment on Re: Starting a Large Project
Re: Re: Starting a Large Project
by petral (Curate) on Feb 12, 2002 at 02:10 UTC
    I pretty much do this but also write an outermost skeleton too.   There's usually some piece or pieces that you have to know how they'll work before you can really do anything.   Also, I get some data/input to feed to my empty shell of a program and even just to look at before I've done much of anything.   (But, then, after a while, you still have to write the darned thing.)
    update:   Oh, and get something visible running soon (for some definition of "works"), then you have the confidence/support to take the time to get it right.   Otherwise, no one can be sure anything's going to come of it.

      p
Re: Re: Starting a Large Project
by count0 (Friar) on Feb 12, 2002 at 15:55 UTC
    I take a similar approach, but even one step further.

    On large projects, I first write the meat of main man pages - consisting mostly of overall functionality, command line switches, etc.

    Then, assuming an OO project (in Perl or C++ -- and most large projects should be OO, imo), sketch out each object, and all of their public methods!
    For me this usually entails writing the document for the use of the class/module.

    I can't stress enough how critical this is on large projects, especially if you are, or will be working with others.

    On countless occations I've seen classes/objects gradually morph as the project progresses... eventually into hideous monstrosities. This is always a direct result of bad planning, or a lack thereof.

    ClassA, for instance, doesn't quite click with a part of ClassB.. so each add another method to fit together more cleanly. Then ClassC comes along and requires a bit different output from each of those, so A and B get new member functions that wrap existing ones, to return a bit different.... and so on and so on.

    If all components of the project are first mapped out, and their external interfaces designed in detail, all that is left is sticking the code in - and when these components are first mapped out, the coding usually is about 10% of the project.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://144749]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (3)
As of 2014-07-26 07:49 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (175 votes), past polls