Code Review – is it a necessary tool in 2024?

What is Code Review?

Code review is the process of checking someone else’s code by a team member or using automated tools. This is an important stage of the development cycle, which allows you to identify errors, improve the architecture and structure of the code, and also increase the overall level of its quality.

7 Reasons why you should include code review in the development cycle

Let’s figure out why code review is needed on a project. There are several main purposes of CR: the need to improve code quality, standardize, and train other team members. Let’s talk about each goal in more detail:

1. Improving code quality
   High code quality means its readability, reliability, and performance, and also simplifies support. Well-structured code is easier for other developers to understand and uses resources more efficiently. Improving code quality reduces technical debt, which speeds up long-term development.
   In addition, code review allows you to identify errors and shortcomings before the code gets to the main branch. For example, if a developer uses an outdated function, the reviewer can point out a more modern equivalent. It seems like a small thing, but in the context of the project, it can save a lot of your time and money.
2. Detecting errors at early stages
   Regular reviews help identify bugs and potential problems before the code gets to production.
3. Code Standardization
   Code reviews help establish uniform coding standards across the team. This is especially important when a project involves developers with different experience levels. For example, a review can ensure that everyone follows the same rules for naming variables and structuring code.
4. Reducing Technical Debt
   Regular reviews help keep the code clean, preventing debt from accumulating. If developers see that inefficient constructs or style violations are discussed and fixed, they will be more attentive to the quality of their code.
5. Educating Employees
   The team can learn from each other by adopting practices and ideas. This increases the overall level of expertise. When a senior developer explains why he chose one approach over another, it helps everyone on the team – at a minimum – to develop their approach to development.
6. Improving Architecture
   Performance and scalability issues are often discussed during reviews, which helps find more sustainable architectural solutions.
7. Understanding and comfortable work in the team
   Everyone understands the logic of changes and participates in improving the project, which leads to more cohesive and productive work. When the verification process is set up as transparently as possible, there are no grievances or discontents in the team. Everything works for the common good of the product.

How to organize an effective code review process?

You should start by choosing: how exactly do you want to conduct the check? Code review can be manual or using automated tools, such as linters or version control systems (GitHub, GitLab). Ideally, you should combine both approaches.

Who is involved in the review process?

As a rule, this is the developer who creates the code and one or more of his colleagues who review the code. The role of the team leader or manager is also important, who controls the quality of the final review and its objectivity.

Code Review Process

Step 1: Preparation

The developer reviews their code for errors and inconsistencies, then creates a pull request (PR). In the PR, they should explain the changes, purpose, and context of the code so that reviewers can understand it more easily.

Stage 2: Review

Colleagues check the code, study its logic, structure and provide comments (usually in the PR itself).

Stage 3: Correction

The developer takes into account the comments and remarks, makes the necessary edits to the code and updates the PR. By the way, edits do not always mean fixing errors, sometimes they ask to work on improving the readability or performance of the code.

Stage 4: Conclusion

If everything is OK, the code is accepted and integrated into the main branch of the project. This completes the code review process, and the developer can be sure that his code meets the team’s quality standards.

Interview with a DevOps Engineer

Do you use code review in your work? On a regular basis or how does it happen?

It is worth noting that code review has several meanings. The first code review is when you yourself, during the development process, check the code for errors, code styling or vulnerabilities, and then your colleagues take a fresh look at it. The second code review is when, having completed a task (not always something related to coding), you need to get approval for quality from colleagues with a higher grade or a team leader. Only after confirmation can you close the task. In this case, code review is, it turns out, a stage of the business process.

In the team, we use code review constantly. If one of the DevOps has a task related to writing or finalizing code (scripts, pipeline, playbooks, etc.), then we act according to the algorithm:

– First, the person saws the functionality according to all the technical specifications specified in the task.

– Then, the executor sets up a meeting with colleagues. At the meeting, we go over the code line by line, discuss the main logic and exception handling, we can touch on the code style (names of variables and functions), and also look at compliance with the principles of OOP and POP (object-oriented programming and procedural-oriented programming). In general, we sketch out all the edits and wishes.

– Next, the colleague responsible for this task finishes everything.

– When ready, moves the task in the tracker by status (from “In progress” to “Code review”), adding links to the work done and indicating the team leader or colleague who will conduct the final code review. If the reviewer has any comments, he returns the task to the “Revision” status and leaves comments either in the comments to the task in the tracker, or in the merge/pull request in the repository, or in a personal message to the performer. And so on again. When there are no comments, the reviewer moves the task to the “Closed” status.

In general, there are a lot of meetings to evaluate code or functionality in my team, since there are a lot of scripts and ideas for their modifications. I want to implement everything and, most importantly, as painlessly as possible for product development *smiles*.

If I get a task not related to coding, for example, creating a database, raising a service, deploying an environment, etc., then after the task is completed, the statuses move, links and other artifacts are attached that show the task is completed, and the code reviewer looks at the correctness of the task according to the technical specifications, if everything is good, he closes it.

Code review – why does a DevOps engineer need it? Are there any code review features for DevOps teams?

In general, DevOps also code quite a bit: scripts, pipelines, playbooks, Dockerfiles, manifests for Kubernetes, etc. And all of this needs to be reviewed to avoid unpleasant situations: timeouts, incorrect behavior, security vulnerabilities, use of unnecessary server and temporary resources, etc.

It is also worth noting that an error in DevOps code, unlike a developer’s code, will often have more global consequences. It is one thing when 1 out of 100 microservices has functionality that does not work correctly, and another when your code has killed 100 microservices on production and the servers are down and no one can work.

Perhaps you have experience when you were in the role of a person who was code reviewed. Describe how you felt about it then, some positive and negative moments.

I always have a positive attitude towards code review, unless it is, of course, a burning deadline and 100500 edits and the same number of conflicts in GIT, *laughs*.
In our team, everyone understands that any detection of errors will allow us to avoid more headaches, stress and negativity in the future due to the fact that everything stopped working or works somehow wrong.

Yes, sometimes, you have to rewrite the code several times, bring it to perfection, it is tiring, you mutter under your breath “Yes, I am not a developer, so I do everything according to patterns”, but then you understand that it is better this way than to respond simultaneously to a large number of angry developers whose service stopped deploying or something else bad happened in life.

How do you feel about code review? Is it necessary or not? Is it relevant now, in 2024, on projects? 

Code review is necessary! Projects are becoming larger, they are growing in code that helps automate processes, and any error in this code can lead to the failure of the entire product that your team has been working on. And it doesn’t matter whether it’s a small team of 5 people or 5 thousand – all this is human labor and time that must be valued.

Do you have any top or situation (story) about specific problems that timely code review helped to solve or prevent?

First, I think every DevOps will note it, code review of pipelines. In addition to the fact that code review here helps to avoid some problems with assembling/testing/deploying services, it also helps to reduce the execution time of these processes. And now you don’t have to wait an hour for the environment to deploy, everything will be done in 15 minutes, *smiles*.

Code review of manifests allows you to adjust the work of services in Kubernetes, especially to track consumed resources (requests and limits), as well as various tests for pods (download, readness, start).

Second, scripts. Scripts can be very different, but they are mainly needed to make life easier for DevOps, who are tired of doing the same actions so that everything works correctly, and the chance of making a mistake immediately becomes less. Wrote a script – debugged, coded and use it with 100% confidence that the script will not perform unnecessary actions, will not create or delete anything important anywhere.

Code review of docker files – allows you to see and eliminate vulnerabilities, reduce the weight of the image.

Code review of playbooks – this is an analogy with scripts, only with the ability to flexibly configure scripts for different operating systems.

Common Mistakes to Avoid During Code Review

1. Micromanagement is a Creativity Killer
   Excessive control can stifle initiative, creativity, and, as a result, motivation. It is better to let developers find solutions rather than dictate every detail. Learn to maintain a balance between standard code and the creative ideas of the team.
2. Lack of Common Code Requirements
   Without clear standards, code quality assessment can quickly become overgrown with misunderstandings and bias. This leads to confusion and different expectations between review participants. It is important to set criteria so that everyone understands what to pay attention to.
3. Going personal
   Code assessment should be constructive. If comments concern the developer’s personality, this can cause tension and conflicts. Use neutral language and discuss only the code.
4. Ignoring comments
   All comments should be taken into account and discussed. If a developer does not respond to comments, this may indicate that his soft skills are not well developed.

How to give constructive feedback?

• Use “I” statements: Phrase your comments with “I” instead of “you” or “yours”, such as “I noticed that…”. This will help avoid an accusatory tone.
• Be specific: Point out specific issues. Try to evaluate the code objectively, without using the “if I were him, I would…” approach.
• Strike a balance: Combine criticism with praise. Don’t roll out a whole list of bugs with the comment “overall, everything is fine”. Try to balance and point out good decisions made by your colleagues.
• Suggest alternatives: Criticize too much? Suggest something! But don’t overdo it. Instead of simply pointing out bugs, offer alternative solutions or better approaches so that the developer can learn.
• Give time to respond: Allow the developer to think about your comments and ask questions if something is unclear. This helps to get rid of the feeling of “overcontrolling”. The main thing is that the free time for thinking does not develop into mistake number 4.

Code review is more than just a code check

Code review is more than just a technical check. It is a way to improve the development culture within a team. It helps to establish close interaction between developers, stimulates the exchange of knowledge and experience, creates a healthy environment for discussing technical solutions and improves skills.

In such an atmosphere, errors are seen as learning steps, not failures. When implemented correctly, implementing code review will ultimately lead you to a higher quality product and happier customers!