How can we speed up code reviews without sacrificing thoroughness of the code reviews?

Question

At our workplace, we use Agile Scrum method. However, we don't really follow it religiously.

But, we do very thorough code reviews. The problem with code reviews is that it's takes a while to document the problems with the code, and send it back to the developer. I suppose they want the code reviews to be documented because it might be good for auditing purposes, and also proves that the code reviewers is actually doing his/her job properly.

But it is seems take a lot of time out of the day where we analyze someone's code, and document mistakes. It would have been better to spend the time doing new development/research/support/maintenance.

How can we speed up code reviews without sacrificing thoroughness of the code reviews?

Answer 1

A couple of suggestions:

Code Quality Tools

It is worth thinking about using automated code quality tools like Findbugs, PMD and Checkstyle.

Ideally get the team to agree on a set of coding standards and implement them as templates in the various code quality tools. Then run the tools from continuous integration and possibly even fail builds when the quality standards are not met.

This won't replace code reviews, but it will hopefully reduce discussions at code reviews relating to coding style, formatting, etc.

Just the fact that you have clear standards will help reduce the time spent on code reviews.

Code Review Tools

There are some good code review tools around.

An example is Crucible.

These kinds of tools are great for helping with the facilitation of code reviews and they also help a lot with code reviews run remotely (say when a team member is working from home).

Answer 2

Are the goals that the review can be audited? or to prove the auditor is doing his/her job? We document them as new tasks/discoveries on our Scrum-board and some just picks them up.

I think the main goal of code reviews is knowledge sharing and finding recurring code mistakes, not the documentation, unless you need it by law :)

Checklist based code reviews: This e-book has a great practical and light-weight strategy for peer code reviews. For a summary if this strategy read my answer to another question on SE.

Pair programming: Some teams think pair programming is a good alternative to code reviews as the code is reviewed by another person during the act.

Answer 3

A few years back my team was in a major time/resources crunch. We solved this question by assigning a senior (me) to do the code reviews.

I used Findbugs to narrow my search and identify obvious bugs, but didn't trust it fully because it was prone to report false positives. For example, it would frequently claim that the logger was and unused variable when I could see that the code logged heavily.

Once I had used findbugs to this extent, I reviewed code in question manually in context to rule out false positives and to find issues the findbugs is ill-equipped to find (Spelling and grammatical errors).

I would spend 30 to 60 minutes prepping for code review, then 10 minutes in the actual meeting. Total resources expended averaged under 1 programmer hour. We never failed to find and eliminate at least three bugs in any meeting.

Answer 4

You could consider using elements of Test Driven Development.

You might find the code reviews quicker, and no less thorough by having the tests created prior to the development, so that the developer can continuously analyse his or her progress until it meets the requirements of the pre-approved test.

This could certainly reduce the back-and-forth nature of the review.

Answer 5

Stop doing code reviews and start pair programming. If the purpose of code reviews is to improve the quality of the code and while helping team members increase their domain knowledge, then pair programming is a much more pro-active form of code review. It also builds quality earlier into your development process.

Speed up = improve efficiency. So you're asking how do we increase efficiency without sacrificing effectiveness. One big down-side of code-reviews is that the team members doing the code review first need to understand the business problem as well as code they are trying to review. This is often done by re- actively reviewing the user story and code after everything is already "done."

A hands-on way to get the same knowledge is through pair programming. You're killing two birds with one stone; implementing the user story and doing a thorough CR in parallel. There's your efficiency gain (and its usually more effective too since most adults learn better through hands-on activities vs passively studying on their own).