As 2008 came to a close, I came across several really interesting articles about peer code review. Since this is typically the time we reflect back on the year gone by and make resolutions for the one just getting started, I realised that adopting code review is not that different from getting in shape.
Like many of you, my New Year’s resolutions included (yet again) eating healthier and working out more. And we all know, these are great things to do regularly, but getting started can be difficult because it’s not part of our current routine and, let’s face it, it’s hard!
Similarly, most development teams don’t need 20 great reasons to understand code review is an important component of successful agile development. But many still struggle with getting code reviews going because it’s not part of our current routine and, let’s face it, it’s hard! Right!?!
Wrong! Thankfully, this year we have help from a number of people including Esther Schindler of CIO.com who recently put together a great series of articles on running an effective code review.
Armed with the right information and tools, I think peer code review should be as easy as 1-2-3:
- Set your goals – Just like starting a new workout routine, you can’t just start running or lifting weights without setting clear goals for your expected outcome.
The same goes for peer code review. It is important to understand the intricate social dynamics involved with the review process and how these affect the outcomes. For example, reviews that focus on code quality and performance work differently (and may take longer) than those more concerned with conformity and clarity. All projects have different needs; what are yours?
Clearly defining what you want your reviews to achieve is the first critical step.
- Get the right tools – Similar to your gym membership or that new Bowflex you got for Christmas, you need to have the right tool for the job.
It is hard to image developers still crowding into conference rooms to spend hours pouring over lines of code. With effective tools, like Atlassian’s Crucible or Google’s Mondrian, making the code review process asynchronous and contextual helps all development teams, not just remote ones. The review process must not be viewed as a burden or distraction from your team’s primary objective, which is writing quality code. It needs to be simple to initiate and easy to interact with for all participates. Automated tools are no replacement for reviews, but they can compliment the review process.
Selecting the right tools is key to fitting your review process into the flow of your development process.
- Have a plan – Think of this as your personal trainer.
Once you have committed yourself to improving your development process with effective code review, you need to implement a plan. Esther provides some great insight into having the right participants lead and moderate the review process and knowing what to look for. She even covers how to avoid politics and misunderstandings along the way.
Coming up with the best approach for conducting the review process within your team will ensure it’s success.