81

I am in the process of trying to sell my organisation on the value of code reviews. I have worked at several places where they were employed. I have seen them used to nitpick styling choices, and functional decisions, and I have seen them used as nothing more than a gut check to make sure nothing dangerous is being implemented. My gut feeling is that the most effective purpose is somewhere between the two options.

So, what is the purpose of a Code Review?

SoylentGray
  • 3,104

4 Answers4

81

There are multiple reasons why you would want to conduct a code review:

  • Education of other developers. Ensure that everyone sees the modification associated with a defect fix or enhancement so that they can understand the rest of the software. This is especially useful when people are working on components that need to be integrated or on complex systems where one person may go for long periods without looking at certain modules.
  • Finding defects or opportunities for improvement. Both the deliverable code as well as test code and data can be examined to find weaknesses. This ensures that the test code is robust and valid and that the design and implementation is consistent across the application. If there needs to be additional changes made, it catches the opportunity closer to the point of entry.

There are several business cases for conducting reviews:

  • Finding defects or issues that would need to be reworked closer to their injection. This is cheaper.
  • Shared understanding of the system and cross-training. Less time for a developer to come up to speed to make changes.
  • Identification of possible enhancements to the system.
  • Opening up the implementation to ensure that testers are providing adequate coverage. Turning a black box into a grey box or white box from a testing perspective.

If you're looking for a comprehensive discussion on the benefits of and implementation strategies for peer reviews, I'd recommend checking out Peer Reviews in Software: A Practical Guide by Karl Wiegers.

Thomas Owens
  • 85,641
  • 18
  • 207
  • 307
53

Code Reviews are a tool for knowledge transfer.

  • When developers review each other's code, they gain familiarity across all areas of the system. This reduces a project's bus factor, and makes developers more efficient when having to do maintenance on a part of the system they didn't write.

  • When a junior programmer reviews a senior's code, the junior programmer can pick up tricks otherwise only learned through experience. This can also work as a corrective against overly complicated code.

    A thorough code review will require frequent checks against various documentation. It's a great way to learn a language or API.

  • When a senior programmer reviews a junior's code, this is an opportunity to iron out issues before they translate into technical debt. A code review can be a good setting for mentoring junior programmers.

Code reviews are not about:

  • … finding bugs. That's what tests are for. It will still frequently happen that a code review finds some problem.

  • … nitpicking on style issues – settle for one style, and use automated formatters to enforce it. But there are many things which an automated tool cannot check. Code reviews are a good place to make sure the code is sufficiently documented or self-documenting.

amon
  • 135,795
16

The most valuable thing I personally get from a code review is confidence that the code is clear to another person. Are variables clearly named? Is the purpose of each chunk of code reasonably obvious? Is anything ambiguous clarified with a comment? Are edge cases and valid values for parameters outlined in comments and checked-for in code?

12

I'd like to add two areas not covered by the other great answers:

One great reason for code reviews is the Hawthorne effect which in our case translates to: If you know someone is going to look at your code afterwards then you are far more likely to write it better in the first place.

Another great reason is for better secure development practices. One only needs to look at Apple's goto fail (an accidental duplicated line of code) or the Heartbleed bug (a basic failure in input validation) to understand the importance of proper code reviews in a secure development lifecycle.

Chris Knight
  • 722