When I were a lad, I were taught to use flow chart stencils....
I was shown how to write data dictionaries, to thought-cloud through the possible data members for these dictionaries, to define the mutable and non-mutable points and abstract away the common elements between these definitions in order to design the code to be written.
All pretty much on paper, before you sat before the computer.
The reason being? Paper was cheaper than electricity, and it took a long time to compile and recompile, and then even longer to debug, a program. Bugs got hidden and only appeared when testing took place.
And if a bug ended up in test, which could obviously have been caught on paper, long before it reached the coding phase, then you got egg on your face. In a nice way, you all knew you had to do more than cut code.
Unfortunately Moores law exists, a blessing, and a curse. As I feel it's made the quality of software design fall, as people can afford to code and compile and try before thinking.
No-one I work with, certainly no-one immediately around me, designs anything on paper, or performs thought exercises on the task before diving at the keyboard. Event when they have dived at a keyboard they're not prototyping, they're immediately producing code for release use, and it's starting to show.
As such, I've instigated a new rule, "if you have to prototype, it must be in a different language to the release code", the language I've stipulated is a python for system scripts or data processing tasks, and C# to replace any windows C++ being produced. For C# I'm still thinking, but Java might be the best option...
This realisation came to be from the back of my mind, and it came from experience, however it seems other authors have had thoughts along these lines:
"One trick to ensuring your prototype code isn't obliged to become real code is to write it in a language different from the one your game uses. That way, you have to rewrite it before it can end up in your actual game" - Robert Nystrom.
No comments:
Post a Comment