Practices
Code Review
Having a second developer read each change before it merges. It catches some defects, and it spreads knowledge of the codebase so that more than one person understands each part.
Part of Quality & Security
Code review means a developer other than the author reads each change before it reaches the main branch. It usually happens in a pull request.
What it is for
Reviewers catch defects the author missed. Over the life of a system, two other effects matter as much. More than one person understands each part of the code, so work continues when someone is away or leaves. Conventions also stay consistent, which makes the code easier for the next person to work in. Review is a good point to spot design problems while they are cheap to change.
What makes reviews useful
Small changes get careful reading, while a change of two thousand lines tends to be approved with little scrutiny. Prompt reviews keep work moving, because a change waiting for review blocks whatever depends on it. Comments are most useful on correctness, edge cases, security and fit with the design.
What makes reviews harmful
Problems start when review becomes a gate to get past or a contest of status. If developers hold work back to avoid difficult reviews, changes grow larger and are harder to review well.
How we use it
Every change is reviewed in a pull request before it merges. Linters in the pipeline handle formatting, so reviewers can spend their time on substance.