Code Review — What It Is, How Code Review and PR Checking Work

What Is Code Review

Code review is a systematic check of code by colleagues before integration. In the Git context, this means: a developer creates a pull request with changes, assigns reviewers, and they study the diff, leave comments, and make a verdict. A reviewer can request changes, approve the PR, or leave a general comment.

Code review pursues five goals: improving code quality (finding defects before they reach production), spreading knowledge (the reviewer learns about new approaches, the author receives feedback), ensuring standards (checking compliance with code style and architectural decisions), reducing bus factor (more than one developer knows the code), and building a culture of responsibility (the author writes more carefully knowing the code will be reviewed).

The opposite of code review is a blind commit: a developer pushes changes to a shared branch without review. This approach is acceptable only in single-developer projects or for urgent hotfixes with subsequent post-factum review. In professional team development, code review is a mandatory step for any change, including documentation and configuration updates.

What to Check in Code Review

Code review should be systematic, not chaotic. Experienced reviewers check code in a specific order: first architecture and logic, then tests, then security and performance, and only at the end — style and naming. This order ensures critical issues are noticed before the reviewer gets tired.

Architecture and logic: does the code solve the task, are there excessive abstractions, are SOLID and DRY principles followed. Complex code that is hard to understand on first reading is a signal that refactoring is needed. The reviewer should ensure that the code does exactly what the task specifies and has no side effects beyond its responsibility.

Tests: do the new tests cover all scenarios — positive, negative, edge cases. Do existing tests pass after changes. Are there any flaky tests that fail inconsistently. Security: absence of SQL injections, XSS, sensitive data leaks through logs or API responses. Performance: algorithm efficiency, excessive database queries, resource leaks.

• Architecture — correctness of the solution, SOLID compliance, absence of over-engineering.
• Logic — handling all scenarios, including errors and edge cases.
• Tests — coverage of new changes, no broken existing tests.
• Security — injections, XSS, CSRF, data leaks through logs.
• Performance — algorithm complexity, N+1 queries, memory leaks.

Review Size: Why 400 Lines Is the Maximum

PR size limit is the most important metric of code review effectiveness. A Cisco study (2015) and subsequent experiments by SmartBear and Google showed that when the review volume exceeds 400 lines, the reviewer’s ability to find defects drops sharply. If a PR exceeds 400 lines, defects are detected with no more than random probability.

Optimal size: 200–400 lines per PR. This volume can be reviewed in 30–60 minutes while maintaining concentration. Google recommends no more than 200 lines per review round with full concentration. If changes are larger, the task should be decomposed into several sequential PRs, each introducing a logically complete change.

Review time: within 24 hours from PR creation. If the review drags on for several days, task context is lost, and the author has to spend time restoring context when responding to comments. Teams with a strong code review culture set SLAs on review: for example, 4 hours for critical changes and 24 hours for regular ones.

How to Write Good Review Comments

Comment tone is critically important for code review effectiveness. A comment like “This is wrong” triggers a defensive reaction and doesn’t provide useful information to the author. A better formulation is a question-suggestion: “What do you think about this approach?”, “This could cause an NPE if user == nil. Maybe add a guard?”. Questions are less confrontational and stimulate discussion.

A good comment structure includes three parts: what’s wrong, why it’s a problem, and how to fix it. Example: “This loop uses O(n²) due to nested contains, which could be slow with 10k+ records. Try replacing with a Set for O(1) lookup.” This formulation simultaneously identifies the problem, explains its importance, and suggests a solution — the author doesn’t have to guess.

GitHub and GitLab support suggestions — inline code change proposals. A reviewer can write: “```suggestion Filter empty strings before processing```” and the author can apply the change with one click. This speeds up minor fixes and reduces the number of review rounds. For major changes, it’s better to write a general comment rather than embedding large blocks in a suggestion.

# Template for good code review comment

# BAD: "This code is wrong"
# GOOD: "We may lose data on empty response.
#         If response.data == nil, the guard returns nil,
#         and user sees empty screen without error.
#         Maybe add a fallback error message?"

# GitHub suggestion syntax:
# ```suggestion
# let result = try? parse(response, fallback: .defaultValue)
# ```

Code Review Workflow in a Team

An effective review workflow is built on four stages. First — the author prepares the PR: writes a clear title (e.g., “feat: add password reset screen”), adds a description of changes, links to the task in the tracker, and testing instructions. Second — the author assigns reviewers via auto-assign (based on CODEOWNERS) or manually.

The third stage — the reviewer checks the code and leaves comments. The fourth — the author makes corrections, responds to comments, and requests a re-review. The cycle repeats until approval is received. After approval, the author performs the merge (or the bot does it). Automation via Mergify or GitHub Auto-merge speeds up the final stage.

An important workflow element is stale PR management. If a PR sits without review for more than 3 days, the process is blocked. Solutions: reviewer rotation (if the assigned reviewer is unavailable), notifications via Slack/Teams, review time limit (SLA). In some teams, a PR without review for more than 7 days is automatically closed, and the author creates a new one after syncing with main.

• PR creation — clear title, description, task links, screenshots for UI changes.
• Assignment — auto-assign via CODEOWNERS or manual selection of 1–2 reviewers.
• Review — check in order: architecture → logic → tests → security → style.
• Fixes — author responds to all comments, fixes blocking issues, requests re-review.
• Merge — after approval and green CI, the author or bot performs the merge.

Common Code Review Mistakes

The first mistake — superficial review. The reviewer quickly scans the diff without diving into the logic and clicks Approve. Causes: large PR, deadline, fatigue. Consequences: bugs reach production. Solution: if there’s no time for a quality review — honestly write “I can’t review today, move it to tomorrow” instead of a formal approval.

The second mistake — excessive criticism (nitpicking). The reviewer leaves dozens of comments about formatting style, variable naming, trivial details. This demotivates the author and drags out the review. Solution: StyleGuide and linters should check style automatically. A human in review checks logic, architecture, and security.

The third mistake — review without questions. If the reviewer only posts Request Changes and Approve but doesn’t ask questions, they miss the opportunity to learn something new. The best indicator of a healthy code review is the presence of discussions in which both sides learn something new. If a review is a monologue by one participant, the process is broken.

• Superficial review — Approve without deep analysis. Solution: don’t review if you don’t have time.
• Nitpicking — criticizing style that should be lint-checked. Solution: automate style checks.
• Personal preference — “I would have written it differently”. Solution: code should work, not please the reviewer.
• Delay — review longer than 24 hours. Solution: SLA on review, escalation on breach.
• Ignoring context — reviewing code without understanding the task. Solution: read the PR description before the diff.