The Importance of Code Reviews
Recently the development team at Wiliam had an afternoon of beer, bonding and buckets (of chicken, fried, courtesy of our good friend The Colonel). The official reason for the catch-up was to discuss as a team positives, negatives and issues we would like to work through as a team. One highlight we all agreed on was coming up with a more structured approach to code reviews.
We are a close team and frequently discuss technologies. As a team, we are not afraid to ask for help or advice from our peers when it comes to development. This will generally involve another developer looking over your code to locate the problem or simply assist in optimising. What we are looking to do as a team is formalise this somewhat. But how?
It’s been said that peer code reviews are the single biggest thing you can do to improve your code. The act of having a peer run their eyes over your work at frequent intervals should be encouraged, and will most likely pick up issues faster and more thoroughly than by the project developer(s) testing their own work. Self-testing is of course always required, but after testing the same code twenty times you become oblivious to its issues.
Unit tests are important but in my opinion should not be relied upon as much as the human factor. Steve McConnell states in his book Code Complete that “software testing alone has limited effectiveness. The average defect detection rate is only 25 percent for unit testing, 35 percent for function testing, and 45 percent for integration testing. In contrast, the average effectiveness of design and code inspections are 55 and 60 percent.”
The main hurdle to code reviews is finding the time. Both you and your reviewer need to set-aside time to review. You also need to decide what you actually want to have reviewed. Through our discussions as a team we have decided that code reviews should be undertaken at the end of each substantial module of core code. The actual mechanics for the review may vary however we have the luxury to simply roll our chairs over to each-others desks to go through code in person. Other options may be to review each other’s code independently and report back flaws via email or a tool such as Collaborator, however we think the personal touch of running your reviewer through the function and purpose of your module while they sit beside you is more valuable. An option for remote workers would be to utilise window-sharing software (GoToMeeting, VNC) and Skype/phone your reviewer.
The ultimate endpoint for code reviews would be pair programming. Is that achievable in a smaller agency? Our initial thoughts is it is not. Resources are finite and not all projects could afford to have a second-chair developer co-writing the same modules. Formalising module reviews combined with existing self-testing, unit tests and user tests should massively help in bug reduction in your finished product.
