Attention! This article is meant for those people, who have an idea of what a code review is and who want to implement this technology in their companies.
When we started implementing code reviews in our projects, we were disappointed by the lack of good materials related to the process organizing from the very beginning. One more aspect that has hardly ever been described is review scaling.
Filling this gap in, we want to share our experience in implementing this wonderful practice by our team. Constructive comments are welcome.
So let’s get it started.
What is it for?
First of all let’s define goals we want to achieve reviewing a code. Of course these goals differ in case of each project and project team. They are influenced by a project character (either one-time or long-term), lifetime (short or long maintenance cycle), and etc. The following goals are the most important to us:
- Decreasing number of defects, detected by our colleagues from the software quality control department and by company’s clients.
- Reducing an application maintenance cost due to increase of code quality.
- Securing quality and quantity of unit tests.
- Securing joint code ownership.
- Securing experience interchange among team members.
- Perfecting a code style. Detecting and discussing style controversies within the team.
Who participates in a review?
Let’s define several terms that will be used within the topic.
- Author is a code developer.
- Reviewer is a developer responsible for all changes getting into a particular module or a path in a project branch.
- Observer is a developer employed as an expert.
When to review?
Now let’s define a place of code reviews in the development process, time of reviews: either before adding a code to a repository (pre-commit) or after adding (post-commit). The choice should be made very carefully, because implementation of code reviews is often quite delicate. Those teams, in which private code ownership prevails (and it happens pretty often), are exposed to the risk most of all. That is why it is reasonable to implement post-commit reviews at first to minimize the risk of failure to meet the project deadlines due to inevitable “holy wars” so common in the beginning. As the participants of a project team gather necessary experience, pre-commit reviews can be implemented.
How does it work?
A developer, creating a review, adds the following participants:
- a reviewer of their group;
- a lead of their group.
The group lead assigns observers from the number of group leads, which modules have been changed.
The group leads assign reviewers from their groups.
What is needed for implementation?
Several terms should be complied with to implement code reviews successfully.
- Before a code is added to a repository, it is surely reviewed by at least one person, who knows it well.
- Developers always know about any changes introduced into their projects by other groups.
- A group lead knows everything what the group does and gets a good overview of any code of the group.
- Within a group, developers have sufficient knowledge of a code written by their colleagues.
- If these terms are complied with, project participants achieve a good level of collective code ownership.
This is it, I think🙂
If the IT community is interested in the topic of a code review and description of our experience, then we’ll dedicate one of our next articles to automation of reviews using SmartBear’s CodeCollaborator.