4 Rules of Thumb for Providing Effective Code Review Feedback

4 Rules of Thumb for Providing Effective Code Review Feedback

The above is the worst case scenario for a code review. Each of the developers thinks the other will look at the code closely. The worst case scenario for a peer code review is when each developer ... 4 Rules of Thumb for Providing Effective Code Review Feedback.

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

Bootstrap 5 Complete Course with Examples

Bootstrap 5 Tutorial - Bootstrap 5 Crash Course for Beginners

Nest.JS Tutorial for Beginners

Hello Vue 3: A First Look at Vue 3 and the Composition API

Building a simple Applications with Vue 3

Deno Crash Course: Explore Deno and Create a full REST API with Deno

How to Build a Real-time Chat App with Deno and WebSockets

Convert HTML to Markdown Online

HTML entity encoder decoder Online

Offshore Software Development - Best Practices

To make the most out of the benefits of offshore software development, you should understand the crucial factors that affect offshore development.

Softagram - Making Code Reviews Humane

The story of Softagram is a long one and has many twists. Everything started in a small company long time ago, from the area of static analysis tools development. After many phases, Softagram is focusing on helping developers to get visual feedback on the code change: how is the software design evolving in the pull request under review.

5 Core Criteria for Selecting Software Development Company - TopDevelopers.co

Check out these five criteria for the selection of your software vendor, and you will never regret having the wrong quality product made for you.

Best Software Development Company in Melbourne

Software Development Company in Sydney, Melbourne. Vrinsoft is Australia based Software Development Agency provides software solutions to increase your sales, reduce costs, and automates business processes with cost-effective, high-quality software development services.

How to Hire an Outsourcing Software Development Company

While outsourcing **[custom software development services](https://bytecipher.net/ "custom software development services")** for all your needs, you can add ample interests to the business by giving access to skilled expertise resulting in the...