A tenant of Agile development, code reviews are intended to spot bugs and improve coding style and quality. However they can cause friction and confusion. At Voxxed Days Zurich, Sebastian Greulach is giving a talk “The Truth About Code Reviews“. We asked him why they cause more good than evil.
Why are code reviews important?
Oh there are many reasons I can think about. The main for me is the opportunity to exchange with my peers. I want to get feedback on my work and discuss it with others. That helps me to find good solutions and gives the others more insight on how I solve the issues. In general it is so simple to conduct code reviews and it has so many benefits, that if done right, it makes a good team atmosphere and brings real quality into the code. So for me it is a key approach to deliver good quality software.
What is the optimum number of people to review code?
A good number of reviewers is mentioned within a talk of Jetbrains, where they do not recommend more than two reviewers. The second reviewer only finds about half of additional defects that the first one did. For a third reviewer, it is even less. So it really does not pay to have more than two.
However it really depends in which environment you are developing, and how many colleagues you can address. It certainly is more important to get yourself a good reviewer, than to just focus on numbers or a strict process. If you get yourself a capable reviewer who can challenge what you have built, you will get the biggest value out of the review.
What is the biggest mistake that you’ve seen happen in a code review, on the part of the reviewer, and the author?
As authors of code are very attached to the products they built and reviewers are not always very respectful with it, this can lead to heated debates. The biggest mistake I experienced was that these two were not conducting reviews any more. But the discussion is what brings real value to the review and this is what we want to keep going. So to keep the discussion heathy, there are certain rules to stick to. In my talk I cover some best practices and try to highlight that the challenge of the code review is not a technical one.
For more, see Sebastian Greulach‘s talk on Thursday: