Don't forget about design in the code crunch
It's always an important thing to be working from a sufficiently complete design when you are coding. Afterall, code without proper design essentially just makes spaghetti.
After going through a number of projects, I've worked out for myself and my team some specific things to do that go a long way in contributing to proper design:
1. Figure out exactly what the thing is supposed to do. In many, many cases HUGE problems can be caused because what the program is supposed to do was never nailed down. Figure it out, and write it down, as detailed as is useful.
2. Do a class diagram or several. If you don't understand how your design fits into objects, you're toast. Take the time to diagram it out, get as detailed as possible. Sometimes when you do this you hit a wall after a bit where there are simply too many unknowns to proceed and make anything useful. At that point I usually go and pound out some prototype code, then return to the class diagram with my new-found knowledge.
3. When you start writing, begin by writing the interfaces. Define how the parts of the system interact with each other. Keep the implementations stubbed, focus on the interaction. This way you iron out the structure points while the actual implementation code is lightweight. After, the bulk of your time is spent (a) working out the correct design and structure and (b) writing all of the intense crazy code that is buried deep inside some methods in a very implementation-specific classes. So the key is to get the design by work right by focusing on getting all of the interfaces talking to each other before you go and writing a bunch of gnarly implementation specific stuff that you have to rewrite when you do design changes.
4. Unit test! Even when you think it's a pain in the arse, unit testing usually saves you time in the long run (the only valid exceptions I can see are (a) if your design is such utter tripe that it's parts absolutely cannot be unit tested without dramatic changes, or (b) if you are writing a part that is very simple and the probability that it will be messed up is very low - but then again, it's easy to misestimate).
5. Document. Some poor sod is going to have to look at your code again (especially if you did a good design!) And of course the scary thing is: It's probably going to be you! So document your stuff before you find yourself asking the rhetorical question "What the heck was this guy thinking when he wrote this?"
I'll post some more stuff as I come up with it.
After going through a number of projects, I've worked out for myself and my team some specific things to do that go a long way in contributing to proper design:
1. Figure out exactly what the thing is supposed to do. In many, many cases HUGE problems can be caused because what the program is supposed to do was never nailed down. Figure it out, and write it down, as detailed as is useful.
2. Do a class diagram or several. If you don't understand how your design fits into objects, you're toast. Take the time to diagram it out, get as detailed as possible. Sometimes when you do this you hit a wall after a bit where there are simply too many unknowns to proceed and make anything useful. At that point I usually go and pound out some prototype code, then return to the class diagram with my new-found knowledge.
3. When you start writing, begin by writing the interfaces. Define how the parts of the system interact with each other. Keep the implementations stubbed, focus on the interaction. This way you iron out the structure points while the actual implementation code is lightweight. After, the bulk of your time is spent (a) working out the correct design and structure and (b) writing all of the intense crazy code that is buried deep inside some methods in a very implementation-specific classes. So the key is to get the design by work right by focusing on getting all of the interfaces talking to each other before you go and writing a bunch of gnarly implementation specific stuff that you have to rewrite when you do design changes.
4. Unit test! Even when you think it's a pain in the arse, unit testing usually saves you time in the long run (the only valid exceptions I can see are (a) if your design is such utter tripe that it's parts absolutely cannot be unit tested without dramatic changes, or (b) if you are writing a part that is very simple and the probability that it will be messed up is very low - but then again, it's easy to misestimate).
5. Document. Some poor sod is going to have to look at your code again (especially if you did a good design!) And of course the scary thing is: It's probably going to be you! So document your stuff before you find yourself asking the rhetorical question "What the heck was this guy thinking when he wrote this?"
I'll post some more stuff as I come up with it.
posted by Brad | 12:58 AM
0 Comments:
Post a Comment
<< Home