in reply to Re: Starting a Large Project
in thread Starting a Large Project
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.
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.
|
|---|
In Section
Meditations