|
"Programming is about thinking, not typing"
-Jeff Straus
Introduction
Often times when there is a new project to work on, the temptation is to sit down in front of the computer and start writing code on the fly. This can work if you're writing a tiny program, experimenting, or if you're just lucky, but it will mostly hold you back from writing a great program due to the time-obliterating processes of compile-and-test, and a likely cumbersome, inflexible design.
The main benefits of design before coding is: a clear understanding of the project, a well-thought out, flexible solution, and a roadmap to complete it.
Planning Process
When I start a new project, I plan and design my code way before I even think about firing up my favorite editor and compiler. For the relatively small projects I work on, the planning and design process takes a few days. However, the time and frustration saved is well worth the effort and time invested in planning.
The First Day
When I initially start working on a project, I usually spend my time getting as much information as I can on the subject. Google is an invaluable resource for finding websites, tutorials, source code, and academic papers (Siggraph, Eurographics, etc). My collection of language, design, and graphics books come in handy too.
The Second Day
The second day is spent really understanding the project and figuring out all the different components and algorithms I'll need to complete the project. This is often accompanied by an intense state of confusion and lack of connectivity. Some design is done, but components aren't well connected or designed to work well with each other.
The Third Day
The third day is pure design and refinement. After letting ideas gel in my mind overnight (and having a good night's sleep or a good nap), my mind becomes clear and focused, and I furiously write down pseudocode on regular white paper. Plain paper and pseudocode are very powerful tools for designing code (and as a side note, Software Development magazine recently awarded 3x5" cards with an honorary tool award). It's easy to create, modify, and redesign code when it's just a sketch on paper. When writing on a monitor, you only have the screen space to work with, but with paper, it's easy to spread it all out around you.
Here's an example of before and after of sketching out code on paper:
 |
 |
 |
 |
| Before pg1 |
Before pg2 |
After pg1 |
After pg2 |
(based on Mark J. Harris' real-time cloud research at www.markmark.net/clouds/)
The Fourth Day
The fourth day is when coding starts. A framework (or skeleton) of how the code will eventually be put together is created, with empty functions (or stubs) acting as placeholders to where real code will go later on.
Days until Completion
The rest of the days are spent filling in the code, maintaining documentation (with doxygen-style comments), testing, refactoring, and fixing bugs. Coding can go on forever, since its fun to keep adding features, but there has to be a stopping point, whether its a milestone, deadline, or even to try something else out.
Common Problems
Sometimes design alone is not enough. Problems that weren't foreseen can be run into, such as adding a new feature to an inflexible design, or sometimes its just due to lack of experience or realizing what's really needed.
For example, I recently finished writing a radiosity rendering program. Conceptually it's pretty easy -- light emits energy that other surfaces absorb and reflect, and as the light bounces off all the surfaces, the room becomes illuminated. However, there are a lot of little components that need to be handled, managed, implemented, and kept track of to make it all happen.
Although I went through the design process I described before, my solution ran into some connectivity problems that I didn't anticipate. Fortunately I was able to make it work, but the design was pretty garbled in the end. This example is also one of the reasons why there are so many versions of any given piece of software out there. (The other, of course, is to make more money by selling a "new and improved" product).
Conclusion
In summary, plan your code before you write it. Coding will be more fun, easier to do, and programmers who come after you to maintain or learn from your code will benefit too.
More Information
For general information related to programming and graphics:
- Flipcode.com: By far the best resource on the web for game and graphics news, articles, tips, and help.
- Hugo Elias: An incredible amount of well-written information on graphics programming techniques by Hugo Elias.
- Google: When you want everything you can get on any topic.
Must-Have Books
Code Complete
This is one of the best books ever written on the whole process of creating code, including design, coding, testing, and management. A must read for any programmer at any level of experience.
Design Patterns: Elements of Reusable Object-Oriented Software
A book on "reusable design". A collection of well-designed approaches to solutions to typical problems in programming. The "patterns", as they call them, are not language specific, although there are examples diagrammed with UML and given in C++, Smalltalk, and other languages. Patterns include creational, structural, and behavioral approaches. A must for any serious programmer.
|
