Code Review — essence, rules, and how to conduct code review in a team

What is Code Review?

Code Review is the process of examining source code by one or more developers before it is integrated into the main project branch. The purpose of review is not only to find bugs but also to improve architecture, ensure compliance with team standards, and spread knowledge. Unlike automated analysis (linters), code review is performed by a human and evaluates readability, logic, and architectural decisions.

According to Google Engineering Practices, 2024, Code Review has two equally important goals: protecting the codebase from defects and teaching developers through feedback. In mobile projects, review necessarily includes checking frameworks (UIKit, SwiftUI, Jetpack Compose), memory management, and network request handling.

Code Review in GitLab and GitHub is organized through Merge Request and Pull Request respectively. Each MR/PR contains a diff, line comments, discussions, and check statuses. According to Microsoft Research (2023), teams that practice regular review release 40% fewer critical bugs to production.

History of Code Review: From Formal Inspections to Asynchronous PR

The first formal Code Review appeared at IBM in the 1970s as "structured inspections" with step-by-step checklists and protocols. In the 2000s, with the spread of Git and distributed teams, review evolved into an asynchronous format via Pull Request. GitHub (2008) made PR a mainstream practice. Modern Code Review is an informal, asynchronous process focused on speed and learning rather than bureaucracy.

Code Review Types: Formal and Informal Approaches

Code Review is classified into four main types depending on the process and participant involvement. Formal (Asynchronous Review) — checking via MR/PR without synchronous communication, most common in distributed teams. Informal — quick CR, when one developer approaches another and asks to look at the code for 5 minutes.

According to Microsoft Research, 2023, pair programming means two developers work at one screen, every line of code is written in real time with on-the-fly review. Over-the-shoulder — one developer looks at another's screen and comments on the code without a formal process. Walkthrough — the code author walks a group of developers through the changes, explaining each decision.

Code Review Checklist: What to Check in Code

Code Review Checklist helps the reviewer not miss critically important aspects. The first category — correctness and architecture: does the solution match the task, is there unnecessary complexity, are the patterns chosen correctly (MVP, MVVM, Clean Architecture). The second category — style and formatting: does the code follow team code style (Kotlin Code Style, Swift Style Guide).

According to Thoughtbot Code Review Guide, 2024, the third block — testing: are unit tests written, do they cover edge cases, do existing tests still pass. Fourth — security: are there no hardcoded tokens, API keys, SQL injections, memory leaks. Fifth — performance: are coroutines/RxJava used correctly, is there no UI thread blocking, no excessive allocations.

• Logic — algorithm correctness, edge case and error handling
• Architecture — adherence to Clean Architecture, MVVM, separation of concerns
• Code style — naming, formatting, consistency with the project
• Tests — presence of unit tests, their completeness and green status

How to Conduct Code Review: Rules for the Reviewer

Code Review requires the reviewer to balance thoroughness and speed. The main rule is to review code in small batches. Optimal volume — 200–400 lines of changes per session. According to Google Research (2022), reviewing more than 500 lines loses effectiveness: the number of missed defects grows linearly with change volume. The second rule — start with architecture, then logic, then details.

According to SmartBear, 2025, comments should be specific: not "this is bad" but "this method violates SRP — extract the validation logic into a separate class." Every comment is a suggestion for improvement, not criticism. If the code is correct but the style doesn't match the reviewer's preferences — leave it without comment. The reviewer should approve a correct solution even if they would have written it differently.

How to Receive Code Review: Tips for the Author

Receiving Code Review is a skill no less important than reviewing code. The author should be open to feedback and see it as an opportunity to improve the solution. The first rule — do not take comments as personal criticism. Code Review checks the code, not the developer. Second — if a comment is unclear, ask for clarification rather than immediately fixing.

According to LeadDev, 2024, before submitting for review, the author must check their own code: run tests, go through the checklist, make sure there are no debug logs or commented code. The MR/PR should include a clear description with context of the changes. The better the description, the faster and more productive the review will be.

Psychological Safety in Code Review

A key aspect of Code Review is psychological safety in the team. If a developer fears harsh criticism or mockery, they will hide problems rather than discuss them. Google Project Aristotle (2017) showed: teams with high psychological safety are 25% more productive. Rules: criticize the code, not the author; ask questions instead of making accusations; thank for good solutions.

Key rule for the author — do not rush to close comments. If a reviewer requested changes, they need to be made, not just replied "ok" and left without fixing. After making corrections — request review again. GitLab and GitHub support Re-request Review for notifying the reviewer.

Code Review Automation: Linters and Static Analysis

Code Review Automation reduces the burden on developers by eliminating formal rule checking. Linters (ktlint, SwiftLint, ESLint) check code style, formatting, and basic errors. Static analyzers (Detekt, SonarQube, Infer) find potential bugs, memory leaks, and security issues before the code reaches a human reviewer.

According to detekt Documentation, 2024, in CI/CD pipelines, linters and analyzers run automatically when an MR/PR is created. If the check fails — the MR is blocked by the Merge button. This ensures that code reaching human review has already passed basic checks. The reviewer focuses on architecture, logic, and readability, not on spaces and indentation.

// Example detekt configuration for Android project
build.gradle.kts (app):

detekt {
    config = files("detekt-config.yml")
    buildUponDefaultConfig = true
    allRules = false
    autoCorrect = true
    debug = false
    parallel = true
}

tasks.named("preMerge") {
    dependsOn("detekt")
    dependsOn("ktlintCheck")
}

Code Review Tools for Mobile Projects

Code Review Tools in mobile development are divided into platform-based (GitLab, GitHub, Bitbucket) and specialized (Gerrit, Reviewable, Crucible). GitLab and GitHub provide built-in functionality: diff comparison, line comments, Threads, Approve/Changes Requested statuses, CI/CD integration. The choice of tool depends on team size and review policy.

According to GitLab Docs, 2025, for large teams (50+ developers), Gerrit provides stricter control: mandatory CI verification before merging, weighted approvals (Verified + Code-Review), and detailed access rights. For small and medium teams, GitLab and GitHub are the optimal choice: configuring Required Approvals, Code Owners, and Merge Checks takes minutes.

• GitLab — Approvals, Code Owners, Merge Checks, MR Templates, built-in CI/CD
• GitHub — Pull Requests, CODEOWNERS, Required Reviews, GitHub Actions
• Bitbucket — Pull Requests for Mercurial/Git, Approvals with Diff comments
• Gerrit — strict verification process, weighted evaluations, Jenkins integration

Common Mistakes in Code Review

Mistakes in Code Review reduce its effectiveness and demotivate the team. First — reviewing too large a volume of changes at once. When an MR contains 2000+ lines, the reviewer misses up to 70% of defects. Second — subjective comments not based on code style or architecture. Comments like "I would have written it differently" without justification provide no value.

According to Google Engineering Practices, 2024, the third mistake — ignoring tests. If an MR does not include tests for new functionality — the reviewer should request them, not approve with "later." Fourth — reviewing at the end of the day or sprint when focus is scattered. The best time for review is the first half of the day, with 30–60 minutes dedicated without task switching.

Review security — the fifth common mistake: reviewers do not check whether the code contains hardcoded secrets, unsecured WebViews with JavaScript, or vulnerable libraries. In mobile projects this is critical: an API key leak could compromise the entire backend.

Code Review in Distributed Teams

For remote teams, Code Review is the primary knowledge sharing channel. An asynchronous format via MR with clear deadlines is recommended: maximum 24 hours for review. Use screen recordings (Loom) for complex architectural discussions. In distributed teams, written documentation of decisions in MR comments is especially important so that context is not lost when switching time zones.