Code review is great for ensuring best practices and educating developers. If you follow a basic set of principles, such as:
- Favoring small pieces of code to review (no longer than 500 LOC),
- Checking the code meets requirements before submitting a review (unit tests OK, documentation updated, …),
- Being kind and respectful when providing comments and recommendations,
then you’ll likely enjoy the benefits of code reviews.
Code review should not be a burden
People practicing code review sometimes feel it gets time-consuming. This can be due to an inappropriate work distribution if one developer is assigned to review all the Pull/Merge Requests (PR/MR).
But it can also be explained by the frequent repetitions of explanations on best practices and coding standards. If a developer did not follow a best practice, you would write a comment in the PR. The PR author will then fix the problem, and finally, you’ll merge and close it.
However, you can’t be sure that another developer won’t make the same mistake later, and you’ll have to write down the same comment again. This happens because most of the code reviews remain within the scope of 2 persons: the author et the reviewer.
I’m sure you already thought:
“This comment I’m writing would be insightful for everyone in my team.”
However, developers not involved in a PR don’t get through it.
Gain efficiency with your team on GitHub
Let’s find out a simple way to overcome that problem. First, you can just install the Promyze web browser plugin for Chrome, Opera, Edge, or Firefox. Once the plugin is ready, you’ll see this new button during a PR review:
Social media