Contents
Code reviews are a form of peer feedback for programmers.
Insights from a study by SmartBear of a Cisco programming team:
Keep change sets small: beyond 400 lines of code, developers’ ability to find defects diminishes. Review effectiveness increases as change set size decreases, so the smaller the better!
Don’t review for more than an hour at a time: as with most cognitively-demanding tasks, effectiveness diminishes over time as the brain tires.
Authors should annotate change sets for reviewers, which allows reviewers to be more focused and effective
Review at least 33% of change sets to trigger what the study calls “the ego effect”: “The knowledge that others will be examining their work naturally drives people to produce a better product.”
The Code Review Pyramid
Gunnar Morling suggests a hierarchy of different kinds of feedback he calls “The Code Review Pyramid”. For example, feedback on API design is more fundamental than feedback on style. Reviewers should spend more time on the more important kinds of feedback, ideally by automating the less-important kinds of feedback such as with linters and formatters. I would add that the more fundamental feedback is best given earlier (so you don’t waste time on the syntax of semantically-inappropriate code) so it’s best to ask for early feedback on new APIs before a final code review.
