Feb/081
Function Driven Design
I have been trying out different ways of doing things while writing my 2D graphics engine. I came up with a pretty neat way of doing things fast with good enough design before implementation, I call it function driven design, don’t know if that already exists or not, but that describes my way.
The Basics
The idea in function driven design is to first design your ‘module’ interface, e.g. write down all your functions to header file. Now this requires a bit discipline, like everything. For each function spent some time (max 5 min) to give it a proper name and right parameters. Time is fixed because I don’t want to be spending eternity on thinking the function declaration. Now after you have written all down you probably already have some ideas about what needs to be changed / improved, now run through a second iteration doing the same thing : check the names, parameters (and their names too!), the general design (think about how it should work) and add new required things.
Second Move
Now you have a interface designed and it is start to continue to source file. Copy all your functions from your header file to your source file in the order they are presented at the header. Then make them all do nothing ‘NULL’, ‘nada’, got it?
After you have functions that can be executed, but won’t do anything you have a prototype of it, kinda. Now start going through every function and add description in few sentence what it should do, if you can’t do it in few sentence then it is probably too long function and at that point I have added TODO in there (explain why) and continued to next funtion. Spent 5-10 mins on each function to come up with the description, again think about how it should work, what it should do, what is it using…
Nearly Implemented
So now you have an interface and null functionality and descriptions for the functions. Do a quick overview of everything : handle the TODO’s, if you spot mistakes fix them right away and so on.
Alright, now you should have a pretty good idea of the ‘module’ : what it should do, how it is designed, what it will use, etc. So we can start implementing, start doing the real implementations : even if some function is not yet implemented use them as you will implement them soon anyway. Compile at least after each function to fix all warnings, errors, etc.
Finishing Touch
After you have implemented your functions go through it once again with small functionality test, e.g. if it is sprite module try that you can create sprite, render & animate and destroy it. Fix all design errors, etc.
As a side note to testing : remember what ever happens it should not ever crash! Even if you shoot nulls, empty filenames, etc. in it, it should just return a clean error message and exit.
Conclusion
I have found this way to be very effective. It has reduced design mistakes, bug and time spent on doing the module and getting it up and running. Used to I had to fix loads of stuff after implementing the module before getting it running, now I’m even sometimes able to get it working right away!
Many iterations and fixed time boxes ensures the quality -> -> makes it is good enough and it doesn’t take eternity, which is really cool.
Enjoy this article?
Leave a comment
No trackbacks yet.
10:52 pm on February 6th, 2008
I sometimes use the same approach. It’s usefull yeah.
You may want to automate some parts, such as copying the declarations to a .cpp or .c file and doing the TODO filling. A simple script could save a lot of time there, if your IDE can’t take care of it already.