Code Reviews… One Month LaterPosted: September 10, 2010
It has been one month since we introduced formal code reviews as part of our development process, and I thought it fitting to do a review of the code reviews – effectively a Code Review Retrospective. Rather than creating a list of n reasons why you should be doing code reviews, I’m simply going to take you through our experiences over the last 4 weeks.
I guess the best place to start is to look at the goals I had for our code reviews. I’ve summarised them as follows:
- Improve quality 
- Share ideas
- Share knowledge of the code
- Share ownership of the code
- Mentor junior programmers
You’ll notice that most of these points can be summarised in one word… TEAMWORK!
I have already seen improvement in a number of these points in only a month. We have ensured that we always submit code for review before allowing it to be handed over for testing, and this has caught a variety of issues in the early stages of development. The issues we’ve identified so far range from subtle issues such as usability, terminology and coding standards to bigger issues such as EIS integration and design.
I also found that the code review process has stimulated more internal dialogue within the development team about how we should go about solving some of the user stories on our task list. As a result, we have achieved the goals of sharing knowledge and ownership of the code and sharing ideas. In turn, this has improved the quality of what we deliver to testing and ensured consistency in our approach as individuals within the same team.
When comparing code that has been reviewed against code that has not been reviewed, it is quite clear that the code reviews help us to deliver code in a consistent manner across the team. That’s quite a big strength in my opinion, as it means that we’re all playing by the same rules, abiding by the same standards, and finding consensus in our approach. Maintainability has improved because the code always looks familiar – so less time is spent figuring out what the last guy did before trying to fix a bug or develop a new feature.
I’ve found that I can keep a much better eye on our delivery by simply monitoring the code reviews. It gives me an incremental view of the changes to the codebase, and allows me to check that we’re meeting the standards we’ve set for quality, simplicity, maintainability, and so on. I think this is essential for any Tech Lead, and also achieves the goal with minimal interference. The productivity of the team should not suffer unnecessarily in order to meet standards – there is often a less disruptive way of achieving this.
What to try next
When we started the code reviews, we were unsure whether to do pre-commit or post-commit reviews. We decided to start with post-commit reviews, as this would be the least disruptive to a familiar development process and would allow us to focus on one new area at a time. Now that we’ve been doing code reviews for a while and have stabilised the process, I’m quite keen to try pre-commit reviews for a sprint or two. I’m sure there will be obstacles to overcome, but the best way to evaluate the two methods against each other is to try them both.
 There are many different views on what “software quality” means. I personally like the points outlined in Wikipedia: http://en.wikipedia.org/wiki/Software_quality#Software_quality_factors