Code review
Having another person read a code change before it becomes part of the product.
Code review is the practice of having at least one other developer read and approve a change before it is merged into the main code. Today it almost always happens through a pull request (GitLab calls it a merge request): the author pushes their change to a separate branch, opens a page that shows exactly which lines were added and removed, and explains why.
Reviewers read the diff and leave comments on specific lines: "this breaks if the list is empty", "there is already a function for this", "can we name it something clearer?". The author answers or updates the change, and the conversation repeats until a reviewer approves it. Meanwhile automated checks run on the same pull request, from tests to formatting rules, so humans can focus on what machines cannot judge.
It catches bugs, but research and experience suggest its bigger value is spreading knowledge: more than one person understands each part of the system, newcomers learn the codebase's conventions, and decisions are written down next to the code. It works best with small changes, which are reviewed faster and more carefully than huge ones, and with a kind, specific tone, since the code is being reviewed, not the person. AI tools now often add a first pass of automated review comments.
Keep in mind
- A pull request shows the exact change and collects the discussion about it.
- Usually at least one approval is required before merging.
- Shares knowledge as much as it catches bugs.
- Small changes get better reviews than big ones.