|Perl: the Markov chain saw|
Re: Software design -- The confussion of buzzwordsby KeighleHawk (Beadle)
|on Sep 08, 2004 at 16:32 UTC||Need Help??|
Based on what you are doing I would suggest the book Refactoring: Improving the Design of Existing Code by Martin Fowler.
Keep in mind you are not doing this for pay, but for fun. Don't let the "right way" take the fun out of it.
The thing that most struck me in your statement was your current process causes you to throw it away and and start again. That is rarely a good process. Just because you suddenly find your code cumbersome or inelegent does not make it wasted. It represents your current understanding of the problem. What your code is telling you is you need to clean it up, not throw it out. It is an awfully rare instance I would suggest throwing away working code.
The problem with the "Software Development Life Cycle" is it assumes at some point in the process you actually know what it is you want. Unfortunatly, the SDLC needs this step to come first and generally it actually comes last.
One of the really good things to come out of extreme programming is this realization and the attempt to leverage rather than supress this natural process. In your case, Refactoring and Test Driven Development are probably the most useful techniques.
If you find yourself skimming but not using certain books, don't despair or even be worried. It may well be you are just not yet ready to make use of those techniques. Find another book that seems to "speak to you" more. Save the other books and come back to them later.
Initially, I would say things like UML and RUP, etc. will be interesting to you not as design tools/methods/processes but more as tracking and documentation tools you use as you go along. Don't worry about designing up front so much as documenting your design as you go. This will not only help you in the proverbial six months later to decipher your code and intentions, it will give you another perspective on your code as you are designing/developing.
If the class diagram is ugly, your code probably is also. If you find it difficult or impossible to write satisfactory, automated test plans for your code, your code is probably too convoluted and poorly designed.
Rather than worry so much about adopting a process, just look to aquire new "tools." Learn about the tools and get comfortable with them. Over time, you will likely start naturally drifting towards a more methodical approach just because the new tools make it easier to do so. But learning new tools **AND** a new process at the same time is a bugger and not very fun.
In all cases, when the programming gets tough, refactor what you have.