3

When I googled "best practices peer code review rate", I found lots of hits that provide best practices for how to conduct a peer code review, but nothing came up for determining a good peer code review rate.

Our team has neither required nor consistently implemented peer code reviews in the past. We're trying to rectify that. However, we don't want to create a process that creates a bottleneck, so I'm assuming that declaring a code review is required for 100% of final commits is a bad idea.

The Question: Is there a best practice or generally accepted percentage of final commits (or other metric) that is used for selecting commits for peer code review?

Improve this question

2 Answers 2

Reset to default
3

I just can tell how the teams I worked with did best: when a developer finished a part of code he or she considered important, they brought it with them to the next review to show to and discuss it with the other team members.
Rotating pair programming-pairs also helps a lot in communicating the current state of a repository.
In my eyes, having a "target peer code review rate" will cause the opposite effect - clutching to a number won't buy the team in but will just add bureaucracy.

Improve this answer
2
  • 1
    That's an interesting observation. We're trying to create process where there hasn't been any before. (And I don't mean bureaucracy. We're trying to avoid that.) I had honestly forgotten pair-programming. I'll have to add that to my list of things we haven't been doing but that add real value. And you're right about the target rate. Thank you.
    – Mike Hofer
    Apr 30, 2018 at 9:08
  • You're welcome! Getting a team to do pair programming can be challenging. In my experience giving them the opportunity is better than to tell them to do it. But you have a good plan!
    – Stephan Weinhold
    Apr 30, 2018 at 9:33
2

Contrary to what you believe, it is not unreasonable to have had at least two sets of eyes on 100% every code change. Every team I’ve worked on for the last five years has had at least one other set of eyes on every change. Sometimes it’s a tool assisted review, sometimes it’s an informal “can you look at this quick”, sometimes it’s a second set of eyes while it’s developed (pairing), but there’s always at least two people familiar with the code. I’ve even worked with teams where one pair would review another pair’s work. That’s four people who are familiar with it!

The thing is though, you can’t just force a review process on a team. That’s a waste of money because they’ll half ass it just to check the box. Review’s are only effective if the dev team voluntarily makes it part of their process because they’re trying to solve a problem.

Improve this answer
1
  • Well said! This is also a lot about team spirit.
    – Stephan Weinhold
    May 2, 2018 at 3:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.