Integrating code inspections into the development process

Attention! This article is intended for people who have an idea of ​​what code inspections are and who want to implement this technique in their company.

When we began to engage in the process of introducing code inspections in our projects, we were unpleasantly surprised by the lack of sensible materials on organizing this process from scratch. Another extremely poorly lit aspect is the scaling up of the inspection process.

To fill this gap, we want to share the experience of implementing this wonderful practice in our team. Constructive criticism in the comments is welcome.

So, let's begin.

Why is this all?

First things first, let's define the goals we want to achieve by inspecting the code. Of course, these goals differ for each project and each project team. They are affected by the nature of the project (one-time or long-term), the life of the project (short or long maintenance cycle), etc. For us, the following goals are most important.

  1. Reducing the number of defects found by colleagues from the software quality control department and customers of the company.
  2. Cheaper maintenance of the application by improving the quality of the code.
  3. Ensuring the quality and quantity of unit tests.
  4. Providing code sharing.
  5. Ensuring the exchange of experience within the team.
  6. Improving the style of writing code. Identify controversial aspects of the style and discuss them within the team.

Who is involved in the inspection?

Let's clarify a few terms that we will use later in the topic.

Author is a code developer.

Inspector (Reviewer) - the developer responsible for all changes that fall into any particular module or path in the project branch.

Observer (Observer) - a developer involved as an expert.

When to inspect?

Now we determine the place of code inspections during the development process, the time of the inspection: before adding the code to the repository (pre-commit) or after adding it (post-commit). The choice is prudent, as the process of implementing code inspections is often painful. The most at risk are teams in which "personal" code ownership prevails (and this happens all the time). Therefore, it is wise to first introduce the practice of post-commit inspections in order to minimize the risk of failure to meet project deadlines due to the initially unavoidable “holivars”. As the project team members gain the necessary experience, you can proceed to the pre-commit inspection.

It must be said that for ourselves we initially chose pre-commit inspections.

How it works?

When creating an inspection, the developer adds the following participants:

  1. inspectors from their group;
  2. Team Leader.

The team leader appoints observers as team leaders whose modules have undergone changes.

Team leaders designate inspectors from their teams.

This approach provides a decentralized appointment of inspection participants and scales perfectly both vertically (in the hierarchy) and horizontally (with an increase in the number of project teams).

What is needed for implementation?

For successful implementation of code inspections, several conditions must be met.

  • Before entering the repository, any code must be viewed by at least one person who is well versed in it.
  • The development team is always aware of the changes that other groups are making to their project.
  • The leader of the group is aware of everything that the group does, and gets a sufficient idea of ​​any code in his group.
  • Inside the group, developers have a good idea of ​​the code that their colleagues write.

When these conditions are met, a good level of overall code ownership by the project participants is achieved.

That's probably all :)
If the topic of code inspection and a description of our experience will be of interest to the habrasociety, then we will devote one of the following articles to automating the inspection process using the SmartBear CodeCollaborator tool.

Thank you and see you soon!