Code Review is the process of checking code for bugs, problems, and design style. Before one developer’s changes get into the code base of a project, it should be checked by teammates and sometimes by developers from other teams. This practice is popular in various companies, especially those working on large projects. Code review reduces the number of bugs that get into production, but at the same time it can take a lot of time resources from both you and your colleagues.
Also, code reviews can be unpredictable in estimating when exactly a new feature will hit the release. Next, we’ll look at how to make going through a code review easy and simple for you and your team members with simple rules.
Why Code Review is difficult and time-consuming
The entry point for a review is the Pull Request (PR). A PR is a request to merge your code changes, which are located in a separate branch, into the main project branch. It is in this request that your code is reviewed, so the ease and quality of Code Review depends not only on the code itself, but also on how the PR is designed.
The first problem that complicates the code review process is poor description of the pool-requests. Since the process itself starts by opening the PR page, it’s obvious to assume that your coworker will end up on a blank page. If there is no description in the PR, it will take longer for the reviewer to understand the context of the problem you were solving.
In addition to the first problem, it is important to emphasize the development history. Any large project eventually grows legacy solutions that new programmers work with. One of the ways to understand why a certain code was written is to look at who it was written by and what pool-request it was injected into the code base (Blame view). It is very sad in this case to come across empty PRs with titles like “Small fix” or “Update module”.
The second problem of Code Review is, of course, the code itself. We won’t talk about the quality and depth of the solution itself, as it depends on the developer’s qualification, but even a well-written code can stay on the review for a long time for such reasons as: a large number of changes (20-30 or more files), unnecessary code refactoring, non-compliance with the code design style and so on.
Let’s consider below the main rules and tips, following which you can speed up Code Review and at the same time simplify the work of yourself and your colleagues.
The main rule – value the reviewer’s time
This rule covers all the main tips and it even sounds obvious. Very often we think of reviewers as people who owe you, forgetting to take care of the proper quality of code and description of the pool-request.
The first reviewer is you
Just imagine as if you are reading your changes for the first time. To do this, just open the git diff changes tab (supported by most popular IDEs).
More often than not, we send commits and create PRs at the end of the day. So, read your code again in the morning. This often helps catch obvious bugs and places where you can improve your code.
Format the Pull Request
It’s important to give maximum context about the task to your colleague before they start looking at the solution. You have a Title and PR Descriptions at your disposal,
Title
The title should clearly describe why you are adding the change. More often than not, it is convenient to duplicate the task title.
Most version control systems support integration with project management services (jira, etc). Use this to include the task ID in the title, which will automatically become a link, allowing you to go to the task in one click and find out more information about the work you’ve done
Minimize changes
A single Pull Request should contain as few code and file changes as possible. This will allow your coworkers to check it out more quickly, without missing critical bugs or losing context. It’s also easier to inject such code into the codebase, as you’re less likely to run into merge conflicts.
If the PR contains an incomplete solution to your problem, be sure to mention it in the description. That way you won’t get obvious questions that will waste your time. And in case the final solution will be realized by future tasks, then add references to those tasks or just describe them.
Make refactoring a separate task
The most tempting thing is to fix bugs and code issues that are not relevant to solving the problem in the file you are working with. Avoid this. Create a task for such changes and move on – you’ll bring more value to your team that way.
A reviewer may even on the simplest and most obvious code refactoring ask to cover the code with tests, which will delay your release indefinitely. And the reviewer will be absolutely right. That’s why it’s better to plan refactoring, or even better – to plan to cover the code with tests if it hasn’t been covered earlier and then create a task for refactoring.
Separate important development steps into separate commits
When working on complex tasks, it is useful to separate logical changes into separate commits. This simplifies code review when there are a large number of changes in PR.
But you don’t want to create commits for every new file or small fix. Use Squash or Amend for this, overwriting old commits with new changes or merging multiple commits into one.
Don’t mix code style changes with functional changes
This point may seem complicated, but it is obvious. It’s very difficult to review code changes where 1-2 lines have been made, resulting in a shift of the entire function by one indent. Such a change will look like you deleted the entire function and rewrote it.