Wednesday, September 12, 2012
Code Complete by, Steve McConnell
Here's a little about me to set the table. As my bio states, I'm a senior software engineer for a smaller company (150 employees). I have a couple Microsoft certifications and am about a decade into my career (how'd that happen?), so I'm certainly no newbie when it comes to software development. That this is the first time I've read McConnell's seminal Code Complete 2 is a travesty and a tragedy.
This book should be every professional developer's Bible.
McConnell writes about the process of development in clear, straightforward language without proselytizing a specific strategy. What he cares about more is making developers more thoughtful and preaching the idea of developing your own software development heuristics. For me, his advice falls in to three categories: things that underscore things I've pieced together instinctively over my career, things that are common sense, and new ways to combat the thorny issues that arise during the development cycle of any program.
One of my favorite chapters is Chapter 9: The Pseudocode Progrmming Process. This process is one that I've used on many occasions for ultra-complex methods, so it was validating to see it in print. After reading the chapter, I wanted to make photocopies and give it to all the junior devs on my team and make them read it before we start on the next big project. The term "pseudocode" refers to an informal, English-like notation for describing how an algorithm, a routine, a class, or a program will work. The PPP defines a specific approach to using pseudocode to streamline the creation of code within routines. The idea is to write pseudocode at "the level of intent". Describe the meaning of the approach rather than how the approach will be implemented in the target language. (McConnell, 218)
Other sections I'd like to call out are Chapter 18 on Table-Driven Methods (something I was unfamiliar with), Chapter 21 (especially 21.3 on Formal Inspections, something I may try to implement at my company), and Chapter 34 - Themes in Software Craftsmanship (basically a high-level review of the major topics in the book).
McConnell draws on quite a few other books and papers to buttress his ideas with hard data about how even mundane things like variable naming and commenting can improve software development and maintenance. One of the things that shocked me, though it shouldn't have considering my experience with QA departments, is how many more defects are found though code and design reviews than are found in testing. The idea set forth in Chapters 20-23 is that it is more cost-effective to find bugs upstream (earlier in the process) than downstream (after coding).
I've always said programming is an art; anyone can do it, but it takes a certain natural talent to be a good programmer. McConnell's idea is that it programming is a craft - a point between art and science. (McConnell, 848) Code Complete is about taking the steps you need to become a master craftsman.
This book belongs on any serious developer's bookshelf.