Geeks With Blogs
Denny Boynton I think, therefore I have a headache!

I was having breakfast with Josh Holmes at the Microsoft MVP Summit this morning and we were asked by one of the attendees about resources for doing effective code reviews. So this got me thinking about the things that have really worked for me in the past and I thought I’d pass them along.

Tip #1: First and foremost, review code often. I’ve worked with many architects that do regular code reviews every one or two weeks. Think about how much code you yourself could write in one eight hour work day. Now take that number of lines of code and multiple it by the number of developers on a typical team, say five. Now, multiply that by five or ten work days. That’s a lot of code to review! Performing a review daily or every other day gives you the ability to review much smaller chunks and you’ll actually have better overall coverage.

I can hear you groaning: “Managing the typical responsibilities of an application architect over the course of a project is hard enough. How can I possibly keep up with daily code reviews?” My answer is: “You won’t have to.” The most critical part of any application development project is the first week. It’s the point where the developers start to build the application. This is the point where an architect should be the singular driving force behind that activity, guiding it, nurturing it and helping it evolve to maturity. Daily code reviews during this start-up period in the project life cycle can address and fix future show-stopping defects before they ever have a chance to grow to fruition. And, if you play your cards right, you be seeding the kind of knowledge in the development team that will avoid future issues from happening (see Tip #4).

Tip #2: Find a static code analysis tool you like and start using it. I look at these tools like the smoke detectors in my house:  Whether my house is on fire (serious) or my kids are burning a pizza in the oven (annoying, but not necessarily serious), I want to know that there is smoke in my house and where, approximately, it is. Use a static code analysis tool to find potential “hot spots” in your code, go there and see what it looks like. I’ve personally used FxCop and Compuware’s DevPartner Studio. Of the two, DevPartner has way more horsepower and capabilities, but having FxCop built into Visual Studio Team System makes it a lot more convenient to use.

Tip #3: Actually read the code. When you’ve locked on to your static analysis tool of choice, don’t let it become a replacement for actually reading the code. Again, a tool makes a good bird dog, but you still need to go retrieve the duck. Reading the code will give you context into the decision making process the developer used when he/she wrote the code. I’ve seen things pop into an analysis window and was ready to go thump the developer on the head, only to read the code and completely get why they went the direction they did.

Tip #4: Separate style from substance. It’s easy to fall into the trap of looking at someone else’s code and think, “That’s not how I would have done it.” Try as hard as you can to divorce yourself from the style of someone’s code and focus on the substance. The two questions I generally ask myself in this instance are: “Will this code work?” and “How easy is it for me to figure out what this code does just by reading it?” The answer to these two questions will generally give me a good feel for the quality of the code.

Tip #5: Make code reviews a learning opportunity. Code reviews can be an opportunity to develop or alienate people on your team, depending on your approach. When doing a review, I obviously want to find as many defects and other issues as I can, but I also want the individual who wrote that code to learn from the outcome of the review so he/she will not make the same mistakes in the future. Taking this approach, you’re ensuring better quality code in your application while making the individuals writing the code better at their job. Ultimately, you won’t need to be as hands-on because the team will be better at writing code and will know what you expect.

Tip #6: Spread the Love. Being so actively engaged in reviewing the teams code, you’ll quickly learn who you lead developers are. Engage them and look for them to help with the work load. Most everybody likes to be recognized for exceptional work. Mentor your leads to become mentors to the rest of the team. This can have several outcomes, of course, depending on the dynamics of the team, so you should take a read on how your team(s) will react, but I’ve rarely seen this not work out for the best.

In my next post, I’ll talk about how these particular tips can be especially effective when working with remote teams, especially those overseas.


Technorati Profile Posted on Tuesday, March 13, 2007 4:08 PM ALM , Role of the Architect | Back to top

Comments on this post: Tips for Doing Effective Code Reviews

# re: Tips for Doing Effective Code Reviews
Requesting Gravatar...
Good suggestions, thank you. Even if it was written 3 years ago, these tips still make sense today.
Left by Caven on Apr 27, 2010 11:00 PM

# re: Tips for Doing Effective Code Reviews
Requesting Gravatar...
I found it useful and agree with Caven.
Left by Santosh on Jun 28, 2010 1:04 AM

Your comment:
 (will show your gravatar)

Copyright © Denny Boynton | Powered by: