Embedding Code Inspections in the Development Process

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


When we started to deal with the process of implementing code inspections in our projects, we were unpleasantly surprised by the lack of sensible materials on the organization of this process from scratch. Another extremely poorly lit aspect is the scaling up of the inspection process.

By filling 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 of all, let's define the goals we want to achieve by inspecting the code. Of course, these goals are different for each project and each project team. They are affected by the nature of the project (one-time or long-term), the project lifetime (short or long maintenance cycle), etc. The following goals are most important to us.

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

Who is involved in the inspection?

Let's clarify a few terms that will be used later in the topic.

Author (Author) - the developer code.

The Reviewer is the developer responsible for all changes that fall into a particular module or path in a project branch.

Observer is a developer who is involved as an expert.

When to inspect?

Now we define the location of code inspections in the development process, the time of the inspection: before adding code to the repository (pre-commit) or after adding it (post-commit). The choice should be approached with caution, since the process of introducing 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 to minimize the risk of delaying the project due to the inevitable at first “holivar”. As the project team members accumulate the necessary experience, you can proceed to the pre-commit inspection.



I must say 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. leader of his group.

The team leader appoints team leaders whose modules have been changed as observers.

Team leaders appoint inspectors from their teams.



This approach ensures decentralized designation of inspection participants and scales well both vertically (in the hierarchy) and horizontally (as the number of project teams increases).

What is needed for implementation?

For the 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 understands it well.
• The development team is always aware of changes that are made to their project by other groups.
• The team leader is aware of everything that the group is doing and gets a fair idea about any code of his group.
• Inside the group, developers have a sufficient understanding of the code that their colleagues write.

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

Here, perhaps, that's all :)

If the topic of code inspection and a description of our experience will be of interest to the habrasoobshchestvo, then we will devote one of the following articles to automate the inspection process using SmartBear's CodeCollaborator tool.



Thank you for your attention and see you soon!