The worst case scenario for a peer code review is when each developer thinks the other will look at the code closely. This happens in real life, more often than you would think. How do you go about ensuring this does not occur? A large part is establishing a healthy code review culture, where the roles and expectations of the parties are known.

For the purpose of this article I am going to focus on the role of the person reviewing the code. Here are 4 rules of thumb to start establishing a healthy code review process:

Rule #1: Let people know right away, if you are the wrong code reviewer.

There is nothing worse than waiting for a review only to find out you sent it to the wrong person and have to start waiting all over again. In addition, if you are not the right person, provide guidance on who may be, if you can.

If you are the right reviewer, do a preliminary check using the following rules:

Rule #2: The review is not more than X lines of code.

Most team have an established a norm for the number of lines that is reasonable, based on the coding language and the nature of the code. There may be a valid reason for the large review (i.e. it is porting a library, it can’t be isolated till all of the changes are committed, …) Many code review system allow you to customize code review notifications to include the size of the review in the notification. Then you know at a glance the size of the review. If your system doesn’t provide this, it is worth creating a script that classifies (tiny, small, … , gargantuan) sizes, as it will bake this rule into your culture.

If you receive a code review that is larger than the norm or so large you’re not sure when you will be able to have time to review it, you should ask the developer to split the review into several smaller reviews. These should build on each other, smaller PRs have many advantages. In the majority of cases, it is possible and leads to better quality of code and reviews.

Rule #3: The review does not bundle more than one change.

If the review is more than one change, it is reasonable to ask for the changes to be separated before the review begins.

Rule #4: The review has a good description and/or context in the description.

Your company likely has a standard practice for code review descriptions. These will be used by the reviewer and possibly hundreds of developers in the future. A good example of guidelines for a PR description may be found in Google’s engineering practices. It is also good to ask for additional context when needed, i.e. design document (this should be added to the description if you had to ask for it), a time to speak with the review so they can explain the changes, etc.

First step of a code reviewer is to see if it breaks one of these rules. If so, comment on code review right away. I encourage all of my teams to return code reviews within **1 Business Day. **There may be the need to go back and forth several times. If is it any slower, it leads to the following unhealthy characteristics:

• **The velocity of the team is slowed down. **Yes, the developer will get other things done, but it takes longer to context switch the longer they have to wait. It also takes longer to be executed and lengthens the feedback cycle on the effectiveness of the code.
• Developers start to avoid code reviews, resulting in larger code reviews. Then the larger the review, the longer it takes… leading to a viscous cycle and questioning the value of reviews altogether.
• **Code heath suffers. **The longer the code review, the more pressure to just check the code in, leading to code that is not as good as it could be and should be.

A good reference for getting started on a set of guidelines for your company is Google’s standard of code reviews

#technology #software-development #code-review #diversity-in-tech #grace-hopper-conference