Unfortunately, there's a lot more to it than that. The book series "Effective C++" by Scott Meyers (I've provided links at the end of this entry to all of the items I rave about, so no need to fire up Google) really opened me up to this notion. It was the first book I had read about programming that didn't teach you how to write code, but how to write proper code. Actually, not just proper code, but great code. It was such a breath of fresh air to pick up a book about programming and not have to see the same step-by-step teaching process. Books like this (you should have already gone and checked it out from your library by now...if not, stop reading and go. now. I'm waiting.) focus on things that too many programmers neglect: writing proper, efficient code that does exactly what you intend it to do, and does so very nicely.
But again, that's just another piece of the puzzle. I've been browsing some programming blogs recently and I came across this one: http://www.gamesfromwithin.com/ There is some really great content in there and I encourage you to check it out. The relevance for this discussion is that the author is a big proponent of agile development and test driven development. If you aren't familiar with those concepts, I hear Google works quite well. The basic run down of agile development is that it's a production mechanism of sorts that stresses quick iteration of software based on client feedback (whether the clients are other programmers working on other features or your actual end-users depending on the type of project you have). A main element of agile development tends to be a team oriented approach that involves things like XP (2 programmers working side-by-side on the same piece of code).
For an example of how well these things can work, check out this entry in the above mentioned blog: http://www.gamesfromwithin.com/articles/0602/000104.html You'll be amazed at how much work gets accomplished with this method.
Test driven development follows with the iterative theme in that you essentially reverse the coding process. How? With the use of a unit testing framework, you write your tests before you write your code. Clearly, the test should fail. Then, you write just enough code to make that simple test pass. The key word there is simple. The tests you design should be very small and simple to implement. The author of that blog suggests between 1-2 minutes to design the test, and not much more than 15 to implement the code to pass the test. "Test Driven Development" by Kent Beck seems to be a godsend book on this design methodology. I just picked it up from the library yesterday and it's very helpful in outlining the process, go get it!
These are just 2 examples of design methodologies in software engineering, but there are a ton of other ones. Some work better for certain things, but the point is that this stuff matters. It's vital in a professional software development environment. Without things like this, nothing would get done, and even if it did, the result would be awful. I encourage you to start learning about this stuff while you are still in school, because chances are you won't have too much meaningful class time devoted to things like this. All of it can only serve to make you a better programmer.
This is where the distinction between "Computer Science" and "Software Engineering" comes in. Software engineering is devoted to stuff like this. It's all about the design, the planning, the process. Computer science tends to be focused on the implementation alone. The curriculum in colleges today leaves much to be desired in my book. How can you send CS majors out into the work field with very little knowledge of software engineering principals? To me, they go hand in hand. You can't write any sort of decent code without a design or a planning process. What about a roadmap or schedule for the project? You can't just "wing it" and expect any worthwhile results to come out the other end. Some people think all of this "management" should be the responsibility of the projects "manager". Maybe so, but I don't think it's black and white. The project manager can't write your test cases for you. The project manager (in the sense that most people think of him/her in) can't set realistic and useful code milestones for you. As a programmer, you can't get to where you need/want to be unless you know where that place is before you start.
I encourage you to read as many blogs by professional developers as you can. These people are wise beyond my years, so I could go on and on, but you're better off hearing it out of their mouths (or fingers...) than having me repeat to you what I've learned from them. The "Games From Within" blog above is really outstanding. I learned more about software engineering in a few hours than I have in 3 years of college. In addition, look for some language-specific blogs by some seasoned vets as well. These blogs tend to focus on many similar topics that the "Effective C++" series does. That is to say, the "how to do it right" as opposed to just the "how to do it". I found this site the other day and it has a wealth of information from blogs by over a dozen different professionals, to regular articles: http://www.artima.com/index.jsp
Good luck, and remember: learning how to program is just the first small step in being a software developer.
Resources You Need To Check Out
Websites / Weblogs
- http://www.artima.com/index.jsp
- http://www.gamesfromwithin.com/
- http://powerof2games.com/
- http://www.aristeia.com/
No comments:
Post a Comment