Microsoft has a long article in ACM Queue on what people think they’re getting out of code reviews, what they’re actually getting, as well as a list of benefits a code review tool should provide.
My main takeaways:
- Requiring two sign-offs is too many for low-risk changes such as renaming internal (not API) methods or local variables — only need one reviewer
- Tag the files/changes that are at the heart of the change
- Small reviews get better feedback. More than 20 files, and a code review isn’t going to provide much, if any, value.
- If code reviews are important, doing reviews should be tracked and rewarded, just like anything else that has value.
- Reviews tend to focus on: comments about maintainability, documentation, alternative solutions, validation, and API usage
- Reviews only identify bugs ~15% of the time, so some other form of validation is important
- A good code review tool can help greatly by recommending reviewers — lightening the burden and getting knowledgeable people involved
- Show entire file to give reviewers context
- There’s no one-size-fits-all solution for code reviews — i.e. each team and code base has different needs and different culture.