There's one absolutely critical task in building software, and that's creating the actual sequence of operations that comprise your software. If you can't get this right, you're nowhere.
Short tangent: think back with me for a moment to the first computer science class you ever took – that one in high school, with the hand-me-down PCs from the typing lab, and the part-time Math/part-time CS teacher. Ah, the heady days when making “hello world” appear on the screen seemed like magic, and HTML felt like a “programming language”.
I’m willing to bet that one of the first lessons you learned was about “routines” – nice, isolated bits of code that did one thing and did it well, bits that could be incorporated into other bits with a simple call. Boom, magic.
There’s always some smart student in the room who asks, “when do I use a routine and when should I just write the code in-line with everything else I’m doing?”
This question has one standard answer given in CS classes all over the world: “write a routine when you’re creating a piece of code that is going to get used frequently.” And for introductory CS classes, for the kind of code written by 16-year-olds, this is a fine enough answer. But for real software, with real users, and more than one developer, there are a lot more reasons to put a piece of code in its own routine. If you can’t name at least three, you need to read the beginning of chapter 7 of Code Complete. And that’s just three pages out of this 800+ page tome! (Aside: by a wide margin, Code Complete is the longest book on my list).If you read nothing else on this list, please, for the sake of software, please read Code Complete. This book is jam-packed with hundreds of little tips that will make your code better, one line at a time
Code Complete will equip you with the skills to start thinking at a high-level about the organization and construction of code. There are two books I recommend here.First, Design Patterns. A lot of developers like to write off Design Patterns as some pointy-haired fluff, but the fact is, in the 14 years since this book was first published, Design Patterns have become established as a useful shorthand for discussing high-order organization of code. If nothing else, you are likely to encounter other people using Design Patterns when they describe their code, and you need to understand the language in order to communicate with them.
There is a risk associated with reading Design Patterns - many people read this book and decide that patterns are the meaning of life itself. I am not advocating that you become a Design Patterns weenie, searching for ways to needlessly incorporate a Strategy or a Factory in your code, or, pure Design Pattern nerd-vana, a StrategyFactory. Nonetheless, there are a lot of fantastic ideas in this book, and your code will be easier to maintain, by yourself and others, if you apply the ideas espoused in Design Patterns.
Next, and finishing out the Code Construction and Design category, is Refactoring, by Martin Fowler. This book is fantastic for the genuine focus on a codebase as dynamic and evolving. For most computer science graduates, working on an existing codebase is completely foreign in academic settings, and one of the first experiences in the professional setting. The ability to think clearly about how to improve the design of existing code, while making strong assurances about the quality of the refactored product, makes an immense difference in your ability to work effectively with software.Once you're through these three books, the raw quality of your code will be immensely better. Code Complete is the longest, but it's a fairly quick read. The other two should be easy to get through in free time.
Coming up tomorrow: now that you're writing great code, we'll talk about the skills you need to go along with that in order to round out your abilities.
No comments:
Post a Comment