Code reviews are essential to high-quality code. Imagine back in high school when you're taking a difficult math test, and then in the last few minutes, the teacher lets you pair up with another student to compare your answers. You almost always will catch extra errors that way, and it's the exact same result with a code review. So, given that we all know that we should do some sort of code review, here are ideas on how to be a good code reviewer:
- Always keep in mind that the other person worked hard on it, and they probably have an emotional attachment. Someone once said something like "Their code is like their baby - don't say 'he looks so ugly', rather make a nice comment like 'Oh, he looks just like his father.' "
- Start with major things first. Don't start nit-picking ("your naming convention isn't good"), if they have major other issues. Focus on their biggest need. If they want your opinion on the data access strategy, that's what they'll be most receptive too.
- Don't just be a rubber stamp - it wastes their time by giving them a false sense of security and tells them nothing new.
- Look to affirm good ideas as well as discourage bad ones.
- Unless they are really missing the basic concepts, don't just tell them to go read some 500 page book - they'll see it as you dismissing them. Give them a tangible example and perhaps provide a web link to a short article or reference guide. If they read that (or they ask for more material), then suggest the books.
- Keep the session relatively short, short enough to fit within their attention span.
- Keep in mind the goal is to make better code for the good of the team, not show off how smart you are.
tags: process
links: digg this technorati
Excellent suggestions. It's also important to keep in mind that *how* you
say things is almost as important as what you say. More tips here:
http://smartbear.com/codecollab-white-paper.php
