Punching out the code
Noah Smith (snortboy) writes:
> how do programmers set up large progs so that it all
> comes together when you actually punch out the code?
There are two main schools of thought on this.
The "top-down" school would have you carefully:
1. Establish the requirements of the program based on user
input.
2. Do the complete high-level design.
3. Do the complete low-level design and pseudo-code.
4. Write all the code.
5. Start testing and debugging.
The "bottom-up" school would have you:
1. Write and test the code for a small, technically-interesting
thing that might be useful in the final program.
2. Play with this code, gradually adding function to it.
3. Write more small pieces and combine them together.
4. Produce a small prototype of the end product.
5. Have some users try out the prototype and get their feedback.
6. Keep enhancing and "growing" the prototype until
it does what you want.
When I worked at IBM in the mid 1980's, the top-down approach
was the *only* accepted approach. Anything else was condemned.
I had to *secretly* build a small prototype of a C compiler
(i.e. bottom-up), while I was officially still in the high-level
design phase. Since no one on our team had written a compiler
before, the prototype helped immensely in understanding what
the high-level design should be, but officially I had to deny that I had
written it.
Nowadays bottom-uppers have come out of the closet, and
most people acknowledge that both approaches can be valid,
depending on what you are doing, and in fact most projects
do a little of both (sometimes working from both ends towards
the middle.) It's helpful to keep in mind the two approaches
and to reflect on the pros/cons of each.
Top-down seems to work when you are doing a project in
an application area that you are very familiar with. i.e. there
is little technical risk - you just have to meet all the requirements.
For games, especially if you are inexperienced, I suspect that
bottom-up will work better. There's no point in designing an
elaborate game, if you ultimately won't know how to code it, or
if the performance is hopeless.
And there's no point in writing a game that turns out to be boring.
You won't know if it's boring or not until you get a simple
prototype working.
Language War (ok it's boring - but I've improved it recently!)
started when my brother, who was lobbying me to write it,
finally got fed up and coded a little demo routine in TRS-80 BASIC
to make the EUPHORIA (it was called the Enterprise back then),
move across the screen. Nothing more, just a little 3-character
image sliding across a black screen. Then he printed periods
randomly to get stars. Then he made a phasor run across the
screen. This was all meant to entice *me* into doing it, but before
he knew it, *he* was spending several hours
a week building it from the bottom up.
As he went along, he would think of ways of making
it more fun, he'd add features, or he'd "tune" the parameters.
He never wrote a high-level design document.
One day, when we were getting sick of it, he said "what if
there was a single huge Klingon lurking somewhere
in the galaxy ...". The huge Klingon (now C++) added
a lot of excitement. You can't decide issues like that
through purely top-down methods.
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
|
Not Categorized, Please Help
|
|
