Code Review

Software consists of text that people write: instructions in a programming language, so-called code. When someone changes something in it, that change doesn’t immediately end up in the finished product. Beforehand, at least one other person looks through the changed text and comments on it. That is exactly what a code review is. It works similarly to proofreading a term paper, except here it’s not spelling that’s being checked, but whether the instructions are correct, understandable, and safe. Only once the reviewing person approves does the change get accepted.

The last filter before going live

Bugs in software cost different amounts depending on when they are found. Someone who discovers a bug during review fixes it in minutes. Someone who discovers the same bug after millions of people are using the app has to deal with outages, data loss, or angry customers. Reviews are therefore not a bureaucratic ritual, but simply the cheapest point at which problems can be caught.

A second benefit is the distribution of knowledge. If only one person understands how a particular part of the system works, that is a risk for the company. Through reviews, several people regularly read other people’s code and get to know the system along the way. Junior developers also get feedback on their style, which turns reviews into a kind of ongoing training.

On top of that, there is external accountability. In banks, in medical technology, or at government agencies, there are regulations requiring that changes to software be approved by a second person. In the process, the review also happens to create a record: one can later look up who checked what, when, and with what justification.

From change proposal to approval

The process is similar in almost every company. A developer first works in her own copy of the project so that her half-finished work doesn’t disturb anyone. Once she’s done, she submits a change request, called a pull request in English. In it, you can see line by line what stood there before and what stands there now. Old lines are usually marked in red, new ones in green.

The reviewing person goes through these lines and writes comments directly next to the affected spot. Typical questions are: Does this also work in edge cases? Is the name of this variable understandable? Is there already a solution for this elsewhere? Was an automated test added? Afterwards, the author makes revisions, and the cycle repeats until approval is granted.

Much of this is now handled in advance by machines. Automated checking tools check formatting and known error patterns, tests run on their own. For a few years now, AI assistants have also been writing initial comments on a change request. They are good at finding careless mistakes, but poor at recognizing whether a solution actually makes sense from a domain perspective. Final approval is therefore still granted by a human.

Green checkmarks on GitHub and the four-eyes principle

Code reviews are most visible on platforms like GitHub or GitLab. There, the code of very many projects lies openly on the web, including that of large companies. You can follow along live as individual lines are discussed. A green checkmark means: reviewed and approved. Anyone interested in programming can read through these discussions without logging in.

In the news, the topic usually comes up after an incident. After major outages or security vulnerabilities, the question regularly asked is whether the faulty change was reviewed at all. Even in attacks on open-source projects, where attackers try to secretly smuggle in malicious code, the review is the point at which it should have been noticed.

Code review should not be confused with testing. Tests check whether the program behaves correctly; a review checks how it is written. Neither replaces the other. And a common misconception is that reviews are primarily about finding bugs. In practice, they are more often about readability, because code is read far more often than it is written.