Iterative Development
(or,
How to drive yourself slightly
less crazy when writing a program...)
- Computer rule #2: Programs
are always more complicated to write
than they seem at first.
- For any program more
complicated than "Hello world!", you should
try to break the development process into small working
parts.
Then after you feel confident that each piece is working, integrate the
pieces together.
- As you start putting the
pieces together, test as many small working examples as you
can. When you discover problems, go back and fix them, and
then test again. Then when you are ready, add a new piece.
- Basically you keep going
around in circles, but moving forward a bit on each cycle.
- For example, say you have a
program to write which your boss describes as:
Go through the user information. If a user has more than 5 late
notices, generate a message and send an email. Anyone who
doesn't have any late notices should be put in our Good Guy database,
and have a Christmas card automatically sent to them.
Handle all errors cleanly. If this crashes in a customer's office
you will need to explain this personally to the vice-president.
- With just a little thought,
you will realize that this "specification" has a lot of things missing.
- Rather than getting lost in
the big picture, it's easiest to
break the problem down into parts. You should write small
working programs that do individual tasks and make sure they work
before going on. You should also ask yourself a lot of
questions before you start any coding. In this example, what
are some of the things you need to think about?
- As you can see, even a
relatively simple project description
generates a lot of small work components. The key
is to get
the small pieces working before trying to make it all work together.
- Error and exception
handling: In a similar way, you want to make
sure that you know how to handle errors. The key is asking
lots
of "what if" questions.
Your First Project
Lets try to apply some of these ideas to the development of Project 1.
Write small programs that do the following:
- Create an array with 3 names
in it. Print out the contents of the array (each entry) using
a foreach loop.
- Create a 5 element
array. Print out the size (number of elements) of the array.
- Generate a random number
between 0 and 10 (use the example.)
Print it out.
- Create a 5 element array
with the following entires: Eric, Brad, Owen, Ronnie, Creek.
Assign the string "Owen" to a scaler variable. Using a foreach loop,
look through the array until you find "Owen" and print out a message.
- Create the same 5 element
array. This time prompt the user for a name, put it in a
scaler variable, and search the list for it. Print out a
message saying whether you found it or not.
- Create an array with the
first names of all of the upper school students. Generate a
random number between 0 and the number of names in the array.
For reference, here are some answers
But of course in Perl (as in most good programming languages), we know
that "answer" is a relative term. Why?