Illiterate code reviews seriously slow down the workflow. When a large number of changes get stuck for a few days (or weeks!), Then the release of the product on the market will have to be postponed. Here are a few reasons why this happens:

There is no standard code design
No automated checks used
Programmers do not independently analyze their code.
Huge Pool Requests
Vague Pool Requests
Missing deadlines for code review

There is no standard code design

Each team should adopt a code format standard (programming standard, style guide), with which everyone agrees. It includes naming conventions, folder structure, code formatting, and a list of best practices, such as unit testing, validation, etc.

The lack of a clear standard and conventions forces every developer to write code as they like, which leads to code disputes. -review. If you see a lot of comments about formatting, naming conventions, and more, then it's time to talk about a common standard.

Your team can either develop their own set of recommendations, or start with well-known recommendations from other companies. Here is an example from Google .

No automated checks used

After adopting code standards, learn the tools to verify compliance with these standards. For almost all languages, there are tools for formatting code, linters and other utilities that you can put in hooks before committing and register in CI / CD systems.

These tools check the code for compliance with design standards and notify the author of violations. The author gets the opportunity to fix problems before sending a pool request, which significantly reduces noise. The more checks that pass automatically, the more time the reviewer has to focus on more serious issues, such as flaws in architecture, implementation gaps, etc.

Programmers do not independently analyze their code.

Before contacting colleagues for a code review, the author must review his own changes. It’s like checking the text of a letter for typos and errors before sending it to the addressee.

In practice, validating your own code is challenging because you tend to subconsciously skip flaws. Here are some ways to improve the quality of self-analysis:

Make a pool request without appointing reviewers and return to it after a couple of hours to take a fresh look at your edits.
Suppress your natural tendency to flip through changes, and instead intentionally look at them line by line.
Follow the checklist: Does the code comply with the design standard? Are all business requirements met? are there any tests for all possible use cases? etc.

Huge Pool Requests

The number of comments to the pool request is inversely proportional to the number of changes contained in it. That is, a large PR → few comments, a small PR → many comments.

The fact is that reviewers do not carefully study the large pool request, but instead tend to scroll through it in order to complete the work faster. This runs counter to the purpose of a code review. Sometimes the opposite happens when the author does not receive any comments for many days, because the reviewer is afraid to start reviewing too much PR.

Break the pool request into smaller pieces that make sense separately from each other. So you will help to consider them properly and quickly.

Vague Pool Requests

Often you are offered a pool request with a vague description or without it at all. The reviewer should understand the meaning of the changes, trying to recall the task that was discussed somewhere in the meeting or in the bug tracker. Therefore, it is better to provide PR with supporting information:

What changes does it contain
What files to start with
Link to the task in the bug tracker
Screenshots if this is some kind of visual change

This information will provide a better context for the reviewer and thereby speed up the code review.

Missing deadlines for code review

One way to stretch the code review forever is to not put any deadlines for the reviewer. Define reasonable deadlines, for example:

The review code should be completed within 48 hours from the moment of sending the pool request.
For hotfixes, the period is 30 minutes.

Thanks for reading! :)

How to speed up code review