I'm fairly new to programming (still a student), and I haven't had much experience with planning out my software development. Usually if it's a large project, the profs break it up into steps for me. If it's smaller, I usually just dive right in. This has worked so far, but I'd like a better process. I'm planning to do a rather ambitious project, and I'm worried that my code will turn out a mess and/or take a lot longer than if I had planned it properly. I'd like a method/technique/advice for planning out my software development.
|
|
Don't mean to offend but your first "ambitious project" is probably going to be a mess, in comparison to what you will be writing say, 5 years from now! Just enjoy the process and don't take yourself too seriously. You are, after all, still learning. It won't hurt if you get an understanding of some design patterns and try to work your code following some kind of methodology like TDD. I recommend a book called "Code Complete 2nd Ed." by Steve McConnell. |
|||
|
|
|
Get a startup FogBugz account and just start logging tasks and bugs. Use it religiously and document every little thing that you do. Be realistic with your estimates (as realistic as you can) and with your prioritizing. You will learn a LOT about yourself and your planning and capabilities by using this tool (or any bug/task tracking software). Also, as @Marlon suggested, I would recommend reading "Code Complete 2nd Ed." |
|||
|
|
|
One of the biggest mistakes you can make is optimizing your code too early... Try to implement one feature at a time. Adopt Test Driven Development to build up a suit of tests around that feature as you go. The tests should pass even as you refactor and continue to build new features. I'd do this no matter what. In terms of having it take longer/shorter, you might want to first understand where you think you are spending too much time. Break the project into a few smallish chunks you can work on and complete in a period of time where you can be totally dedicated to the project (that is, set aside 2 hours, and pic what you think is 2 hours of stuff you can complete) At the end of the 2 hours, review (mentally) what you completed and what was taking more/less time than you thought. Review where the project is, and evaluate the rest of the work and see if you need to adjust your choices for design or implementation. When you complete the project, ask yourself what you might -specifically- do to improve the next time. Think about the time spent researching/designing the project vs coding vs re-factoring vs chasing bugs. If you find yourself "out of balance" in one of these, decide what you might try differently the next project. Finally - talk to the others taking the class with you and see how they are approaching the projects. Learning from your peers almost always pays off! good luck and have fun in school! |
|||
|
|