We are trying out mandatory code review on each commit -- nothing gets into master that hasn't been validated by at least 1 person not the author -- for a couple of sprints. We have buy in from both developers and management (which is an amazing situation to be in) and we want to get some of the benefits that it is known for:
- obvious bug reduction
- more awareness of changes happening around the project
- the "I know someone is going to look at this so I won't be lazy"/anti-cowboy effect
- increased consistency within/across projects
But we're introducing something that is known to reduce velocity, and if done wrong could create a stupid bureaucratic step in the commit pipeline that doesn't do anything but take up time. Things that I'm concerned about:
- reviews devolving into just nit picking
- (hyperbolically) people opening up huge architectural issues as part of a two line commit review.
- I don't want to bias answers with other things.
While we're all reasonable people and we'll be doing a lot of self analysis, we could definitely use some battle-won insight into what kinds of things we should be trying to accomplish in a review session to really make reviews work for us. What are some guidelines and policies that you have found to work?