Are Code Reviews Worth It? 345
JamaicaBay writes "I'm a development manager, and the other day my boss and I got into an argument over whether it's worth doing code reviews. In my shop we've done both code reviews and design reviews. They are all programmer-led. What we've found is that code reviews take forever and tend to reveal less than good UI-level testing would. The payback on design reviews, meanwhile, is tremendous. Our code is intended for desktop, non-critical use, so I asked my boss to consider whether it was worth spending so much time on examining built code, given our experience not getting much out of it. I'm wondering whether the Slashdot crowd's experience has been similar."
Synergy, leverage, low hanging fruit, etc.. (Score:5, Informative)
Having worked on life critical type systems where every line of code was reviewed before making it into the product, I have to say that I've seen them add a lot of value when done properly.
They also cost a lot.
The first question I would ask in your situation is: are you doing them right?
Do bugs get discovered later after deployment? Are the bugs in areas of the code that were supposedly reviewed? If so, you might be doing it wrong.
And as much as we _hate_ the word... I have to say it...
METRICS!
If you truly want to make a decision on whether code reviews are worth it.. you need to know:
- how much does it cost to conduct the reviews
- how many defects are discovered in the review versus how many make it out the door (in other words, how good are you at it)
- how how much more does it cost you when a bug gets discovered after deployment? In a life critical system, it costs a fucktonne.. in a desktop app.. it may not be that bad.
Once you know these, the picture should be clear
When done right (Score:5, Informative)
Code Reviews are useful when they are done right. But before you start using code reviews you should introduce automated static analysis of the code during the builds. A lot of crap can be discovered by static analysis. This saves you a lot of effort on the tedious parts of code reviews.
Re:Synergy, leverage, low hanging fruit, etc.. (Score:3, Informative)
Sadly every security vulnerability on the products I've worked on were found after shipping in code that was reviewed (and not only that - sometimes very obvious bugs - like treating strings as fixed values, and not checking or sanitizing inputs).
So I guess they either have to be done right, or they aren't all that useful.
Re:Are they worth it? (Score:5, Informative)
http://en.wikipedia.org/wiki/Code_review [wikipedia.org]
There are apparently a couple different kings of things that are both called "code reviews", which one are you talking about? There's also the issue that they're supposedly (as in, according to actual studies) pretty good, so maybe you could do them slightly differently and get much better (more in line with the study results) effects.
More details on what your version of a "code review" and a "design review" are would probably get better answers...
Yes, yes, and then some (Score:5, Informative)
Even the best programmers make mistakes. Having another set of eyes is invaluable for detecting bugs before they become problems. Having to explain in words the rationale for a design decision often helps you better understand your own design, and to see potential problems with it. Sometimes you come up with something better on the spot. Also, if you get hit by a bus, your fellow programmers can take over without having to reverse-engineer your thoughts. Please, more code reviews.
Re:Are they worth it? (Score:3, Informative)
Google is using a code review tool called Mondrian. It was originally written by Guido van Rossum (Python's creator).
He created an open source clone to be used with Subversion, Rietveld:
http://google-code-updates.blogspot.com/2008/05/guido-van-rossum-releases-mondrian.html [blogspot.com]
http://codereview.appspot.com/ [appspot.com]
These tools are great but they are only as good as the guidelines for the reviews. Some reviewers will always say yes to requests, while others will be too anal. What happens? Most people will avoid strict reviewers and send their code to the easy ones. Doing a good review takes time so there need to be incentives to give good reviews: if you spend 2-3hs doing reviews in a day you just lost 25% productivity on your code, while helping an other developer write better code. Overall it's better for the team and the company but can actually hurt the perceived performance of your better developers while in fact they're pulling everyone else up. Just make sure good reviewers are getting as much recognition as good/productive code writers. Same thing goes with lenient reviewers, they should share the blame when bad code they reviewed brake the build. If you don't understand the new code, then it needs to be re-factored by the submitter to improve readability or you are not the right person to do the review.