there are basically a few things a novice can get into the habit of doing:

the first is to have a mission statement and game plan. knowing exactly what you plan to do and where to stop at.

second, do unit testing. when you add a feature, isolate and and ensure that it works properly. Its a good idea to have a second, archivable app, that demonstrates the feature in a straight forward and uncluttered manner.

third, archive source regularly, if you arent using a program to do this for you, just take all of your files and zip them up with a name like source06_28_04.zip and stick it in your archives folder. this way if your app seems to get completly and mysteriously broken, you can rollback to an old version.

the way to actually design and build your system, however, is really only provided through experience, and is based a lot on what your doing. The more you program, think about programming, and learn about programming, the more youll understand system design and good/bad design.

there are about a million books and articles on the topic though, try googling program design or design patterns.

Its also a very good idea to keep a journal or large note book. It need not be neat or tidy, or particularly impressive looking, but when you finish one dont throw it away, file it somewhere.

I put a variety of things in mine, here are some:

1) "Low level" diagrams and text explaining algorithm definitions. Sometimes (esp. when tired) I get confused in regards to how an algorithm should work/is already working. It helps organise your thoughts if you get it down on paper by writing down, stage by stage what the algorithm is doing, even drawing boxes for variables, or lines of boxes for arrays etc.

2) "High level" diagrams showing classes and the relationships between them. Sequence diagrams showing the order in which things happen. Even if you think you dont need to do such diagrams, do them anyway; learn UML if you dont already know it.

3) High level explanations on architecture, patterns, and changes made to requirements, plans etc.

4) Conversations, ideas, thoughts and other notes. Solutions to problems, work-arounds, compromises and anything else that might be useful.

Jon

- Keep a pad of paper by your PC so you can draw out class relationships and diagrams and figure out equations and whatnot.

- Keep a running ToDo list file. Add entries whenever you think of something. When you sit down to program, open the list and just start picking things off the list one by one.

- Comment everything . Comment it in such a way as to explain to someone else. That someone else might just be you in 6 months :-)

- Logically organize your source code into nicely sorted subdirectories. Don't just lump the whole mess into one big folder unless your project is trully small.

- As far as code goes, compartmentalize everything and only provide simple interfaces. For instance, this week i programmed a light flash effect in 2D OpenGL. It's constructor has *11* parameters! (i like the variety potential). Later i decided it was ugly, so i changed it to just the screen location X,Y and the type. I later define the types, but it simplifies the interface a whole bunch. so now instead of

LightFlare(10,50,0,100,0,800,2000,1.0,1.0,1.0,1.0)

it's just

LightFlare( 10, 50, BLINDING_FLASH );

- Be sure to sit down and figure out how your whole system is going to work before you type it up. "Think as you go" is not a good way to do it, especially on larger projects. Try to get your architecture humming nicely with a few test subjects before programming all the subjects then the framework for them. You may find yourself redoing it all if it doesn't work out :-(

[edited by - leiavoia on May 29, 2004 2:28:14 PM]

Also, if you''re working in a team, it is a good idea to make a "design document", i mean, some reference on how to design your code. Number of tab spaces, naming conventions, etc... this may seem a bit boring, but it will surely make the whole code easily readable to all team members, improving speed.