Table of Contents
Use automation to save time
When performing a code review, a reviewer needs to stay focused and concentrated in order to detect critical and important issues and inform an author about them. Unfortunately, almost every code contains a large number of small issues like whitespace errors that make the reviewer lose concentration and focus.
In order to facilitate the review process and help the reviewer focus on more important things, an author can use a formatting tool that can automatically fix such minor issues as:
- Whitespace errors
- Code builds verification
- Identification of unused imports
- Identification of unused variables
The most popular automated tools for code review are Travis or CircleCI but you can choose other options.
Introduce a style guide
Disagreements between an author and a reviewer are quite a common thing that can lead to bigger conflicts in the future. The introduction of a style guide for developers is a great way to resolve disagreements especially when it comes to code review.
A style guide is a collection of rules that defines how the developers in your company should write their code. It may include such things as naming conventions or the use of specific programming languages.
The introduction and deployment of a style guide will save lots of time during code review as both the author and the reviewer will no longer need to argue over certain things. You can either use an existing style guide (i.e. from Google), write your own or merge the two options.
Split huge changes into smaller ones
When an author submits a big feature, it might take a few days for a reviewer to review it. In order to speed things up, an author can split this big change into several small ones. For example, one change will define the API for a submitted feature and the other change will be adding implementation for the interfaces.
The review of small and medium changes is more efficient since reviewers are able to maintain concentration. A study by a SmartBear studio revealed that the maximal number of lines of code to review at a time is 400. The same study recommends reviewing for no longer than an hour before taking a break. Otherwise, a reviewer will lose focus which will result in poor review results.
Write high-level feedback first
One of the most common mistakes that reviewers make is writing too many low-level notes instead of writing high-level ones. While such an approach seems reasonable, it has a few drawbacks.
There may be too many low-level notes and the author will spend too much time on resolving the issues. As well, the number of low-level notes can simply confuse and overwhelm the author, resulting in stress and possible conflict.
If a reviewer writes high-level notes first, he will kill two birds with one stone. First, the number of high-level notes is usually smaller than the number of low-level notes. That means, the author will not be stressed too much. Second, the resolution of high-level issues will most probably resolve a number of low-level ones, meaning, the review will be completed faster.
Provide examples to an author
When reviewing code, a reviewer often leaves suggestions on how to improve certain areas. What many reviewers tend to overlook is the fact that the author might not be aware of the suggested techniques and methods. So when an author receives such a note, they will have to spend time on research instead of focusing on fixing errors.
Instead of simply writing a suggestion, try providing an example. In this way, you will show that you are supportive and it will help the author quickly learn a new method.
Do not ignore the importance of good communication
Communication is one of the cornerstones of efficient code review that often gets overlooked. Due to the number of tasks and deadlines, most developers do not have enough time to craft lengthy feedback or patiently explain obvious things to an author. An author, in turn, gets stressed and annoyed and, as a result, a conflict is inevitable.
In order for everyone to benefit from code review, it is important to follow certain guidelines on communication. Here are a few things to consider:
- Try avoiding negative comments and don’t forget to emphasize good decisions that the author made
- Replace “you” with “we” or dismiss it (i.e. “can we use X instead of Y?”)
- Phrase your notes as requests and suggestions, not direct commands
- Retain a positive attitude and try to educate instead of picking up mistakes
A positive code review culture implies that everyone understands its importance and is ready to receive and provide feedback. Thus, we highly recommend that you promote and adopt code review and nurture a positive code review culture for the benefit of the employees and the company.
Tools for code review
As we already said, there are plenty of tools that can help you perform code review. Here are some of the most popular ones.
Collaborator
This tool allows team peer code and document review and helps development, testing, and management teams work together on the same task. In this way, the task becomes transparent and everybody stays on the same page.
Most notable features:
- Easy integration with different SCMs and IDEs
- Option to build custom review templates
- Automatic notifications
- Configuration of peer reviews rules
Gerrit
While Collaborator is suitable for teams of any size, Gerrit is recommended for small and medium-sized teams. It is a free and web-based tool for code review that is known for its close integration with Git.
Most notable features:
- Integration with Git and repository management option
- Option to manage multiple repositories
- Very configurable hierarchy
- Side-by-side difference viewing
Crucible
Since 2007, Crucible belongs to Atlassian and is among the most popular tools for code review. This web-based tool is suitable for teams of any size and is rather light-weight which is another advantage.
Most notable features:
- Inline comments and discussions
- Activity streams with real-time updates and comments
- Integration with Jira
- Charts and reports for stakeholders
As for SoftTeco experience, we used GitHub, GitLab, and Bitbucket for performing code review for our iOS applications. However, you are free to explore the options and choose the one that would be most suitable for you.
Summary
Code review is a must-have practice that contributes to better code quality and ensures that developers collaborate and communicate in an ongoing manner. At SoftTeco, we have our code review guide that is available to all developers and describes all the needed steps, style guides, and approaches in detail. In this way, we ensure that all developers focus on quality and can always address this guide in case any question arises.
We highly recommend that you follow the above mentioned code review guidelines in order to speed up the development process and save time and effort of your developers. And if you know other valuable code review practices please feel free to share with us!
Comments