Author: Sven Reichard
Date: 02:46:58 07/01/02
Go up one level in this thread
Russell, let me offer a third approach. I don't mean to be preaching OO practices, I just want to describe how I work. The idea behind this kind of design has been called "the simplest thing that works (tsttw, for some)". The basic premise is that you don't know at the beginning what you will need down the road. So you defer design decisions as long as possible. In practice, that means: 1) Figure out what the program is supposed to do. Start with simple things, like reading Forsythe strings for example. 2) Write tsttw, i.e., just enough code that it does what you required under 1). Use the simplest design possible - first make it run correctly; you can worry about performance later. 3) Write code that tests the code you have just written, thus make sure it fits the requirements. (Some people, including me, do Step 3 before Step 2.) 4) *Keep the testing code*, and have it rerun after each compilation. (make check, if you work under Unix) 5) Go to 1, i.e., add functionality. If at some point you figure out that your data structures are inadequate because a) it's difficult to add new functionality or b) performance is really bad, you change the data structures. If your code is well-structured, the changes should be fairly local. You always can be sure that your changes don't break the existing code, since you have your testing code from 3). Now I don't say that this leads to the fastest possible code, but it leads to relatively bug-free code, and prevents the "programmer's block" that many of us experience before starting to write our programs. If you want to know more about this philosophy, grab a copy of "Refactoring" by Martin Fowler, or just about any book by Kent Beck. Cheers, Sven.
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.