Code Review — 本质、规则以及如何在团队中进行审查

什么是 Code Review？

Code Review — 由一个或多个开发人员在将源代码集成到项目主分支之前对其进行检查的过程。审查的目的不仅是发现错误，还包括改进架构、符合团队标准和传播知识。与自动分析（linter）不同，代码审查由人类执行，评估可读性、逻辑和架构决策。

根据 Google Engineering Practices，2024，Code Review 分为两个同等重要的目标：保护代码库免受缺陷侵害和通过反馈培训开发人员。在移动项目中，审查必须包括对框架（UIKit、SwiftUI、Jetpack Compose）、内存管理和网络请求处理的检查。

GitLab 和 GitHub 中的 Code Review 通过 Merge Request 和 Pull Request 组织。每个 MR/PR 包含 diff、行注释、讨论和检查状态。根据 Microsoft Research（2023）的研究，定期进行审查的团队向生产环境发布的关键错误减少 40%。

Code Review 历史：从正式检查到异步 PR

第一个正式的 Code Review 出现在 1970 年代的 IBM，作为带有逐步检查清单和协议的「结构化检查」。2000 年代，随着 Git 和分布式团队的普及，审查演变为通过 Pull Request 进行的异步形式。GitHub（2008）使 PR 成为大众现象。现代的 Code Review 是一种非正式、异步的过程，强调速度和学 ，而不是官僚主义。

Code Review 的类型：正式和非正式方法

Code Review 根据流程和参与者的参与程度分为四种主要类型。正式（异步审查） — 通过 MR/PR 进行检查，无需同步通信，在分布式团队中最常见。非正式 — 快速 CR，当一个开发人员走近另一个开发人员并要求在 5 分钟内查看代码时。

根据 Microsoft Research，2023，结对编程 — 两个开发人员在同一屏幕前工作，每段代码都是实时编写并「即时」审查。Over-the-shoulder — 一个开发人员看着另一个开发人员的屏幕，无需正式流程即可评论代码。Walkthrough — 代码作者带领一组开发人员查看更改，解释每个决策。

Code Review 检查清单：代码中要检查什么

Code Review 检查清单帮助审查者不遗漏关键重要的方面。第一类 — 正确性和架构：解决方案是否符合要求，是否存在过度复杂性，模式（MVP、MVVM、Clean Architecture）是否正确选择。第二类 — 风格和格式：是否遵守团队的代码风格（Kotlin Code Style、Swift Style Guide）。

根据 Thoughtbot Code Review Guide，2024，第三块 — 测试：是否编写了单元测试，是否覆盖了边界情况，是否破坏了现有测试。第四 — 安全性：是否有硬编码的令牌、API 密钥、SQL 注入、内存泄漏。第五 — 性能：是否正确使用协程/RxJava，是否阻塞 UI 线程，是否存在过多的分配。

• 逻辑 — 算法的正确性、边界情况和错误的处理
• 架构 — 遵守 Clean Architecture、MVVM，分离关注点
• 代码风格 — 命名、格式、与项目的一致性
• 测试 — 单元测试的存在、完整性和绿色状态

如何进行 Code Review：审查者规则

Code Review 要求审查者在彻底性和速度之间取得平衡。主要规则 — 小批量检查代码。**最佳数量** — 每次会话 200–400 行更改。根据 Google Research（2022），超过 500 行的审查会失去效率：遗漏的缺陷数量随更改量线性增加。第二条规则 — 从架构开始，然后是逻辑，然后是细节。

根据 SmartBear，2025，评论应该具体：不是「这不好」，而是「这个方法违反了 SRP — 将验证逻辑移到单独的类中」。每条评论都是改进建议，而不是批评。如果代码正确但风格不符合审查者的偏好 — 不加评论。审查者应该批准正确的解决方案，即使他自己会以不同方式编写。

如何接受 Code Review：给作者的建议

接受 Code Review — 一项与检查代码能力同等重要的技能。作者应该以开放的态度对待评论，并将其视为改进解决方案的机会。第一条规则 — 不要将评论视为人身攻击。Code Review 检查的是代码，而不是开发人员。第二条 — 如果评论不清楚，请要求澄清，不要立即修改。

根据 LeadDev，2024，在提交审查之前，作者应该自己检查代码：运行测试，浏览检查清单，确保没有调试日志和注释掉的代码。MR/PR 应包含清晰的描述，说明更改的背景。描述越高质量，审查就越快、越富有成效。

Code Review 中的心理安全

Code Review 的一个关键方面 — 团队中的心理安全。如果开发人员害怕受到严厉批评或嘲笑，他会隐藏问题而不是讨论它们。Google Project Aristotle（2017）表明：具有高度心理安全的团队工作效率提高 25%。规则：批评代码，而不是作者；提出问题而不是指责；感谢好的解决方案。

关键规则 对于作者 — 不要急于关闭评论。如果审查者要求更改，必须执行，而不是回答「好的」而不做修改。修改后 — 再次请求审查。GitLab 和 GitHub 支持 Re-request Review 以通知审查者。

Code Review 自动化：linter 和静态分析

Code Review 自动化通过消除正式规则的检查来减轻开发人员的负担。Linter（ktlint、SwiftLint、ESLint）检查代码风格、格式和基本错误。静态分析器（Detekt、SonarQube、Infer）在代码进入人工审查之前发现潜在的 bug、内存泄漏和安全问题。

根据 detekt 文档，2024，在 CI/CD 管道中，linter 和分析器在创建 MR/PR 时自动运行。如果检查未通过 — MR 将被 Merge 按钮阻止。这确保进入人工审查的代码已经通过了基本检查。审查者专注于架构、逻辑和可读性，而不是空格和缩进。

// 适用于 Android 项目的 detekt 配置示例
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 工具

Code Review 工具在移动开发中分为平台工具（GitLab、GitHub、Bitbucket）和专用工具（Gerrit、Reviewable、Crucible）。GitLab 和 GitHub 提供内置功能：diff 比较、行评论、讨论线程、Approve/Changes Requested 状态、CI/CD 集成。工具的选择取决于团队规模和审查政策。

根据 GitLab 文档，2025，对于大型团队（50+ 开发人员），Gerrit 提供更严格的控制：合并前通过 CI 进行强制验证、加权批准（Verified + Code-Review）和详细的访问权限。对于中小型团队，GitLab 和 GitHub 是最佳选择：Required Approvals、Code Owners 和 Merge Checks 的配置只需几分钟。

• GitLab — Approvals、Code Owners、Merge Checks、MR Templates、内置 CI/CD
• GitHub — Pull Requests、CODEOWNERS、Required Reviews、GitHub Actions
• Bitbucket — 适用于 Mercurial/Git 的 Pull Requests，带 Diff 评论的 Approvals
• Gerrit — 严格的验证流程、加权评估、Jenkins 集成

Code Review 中的常见错误

Code Review 中的错误降低了其效率并打击团队士气。第一 — 一次性检查过多的更改。当 MR 包含 2000+ 行时，审查者会遗漏高达 70% 的缺陷。第二 — 不基于代码风格或架构的主观评论。诸如「我会以不同方式编写」之类没有依据的评论毫无益处。

根据 Google Engineering Practices，2024，第三个错误 — 忽略测试。如果 MR 不包含新功能的测试 — 审查者应该要求它们，而不是批准「以后再说」。第四 — 在一天或 sprint 结束时检查，此时注意力分散。审查的最佳时间 — 上午，专门留出 30–60 分钟，无需在任务之间切换。

审查安全性 — 第五个常见错误：审查者不检查代码中是否有硬编码的秘密、未关闭的带有 JavaScript 的 WebView、库中的漏洞。在移动项目中这很关键：API 密钥泄露可能导致整个后端受损。

分布式团队中的 Code Review

对于远程团队，Code Review 是知识传递的主要渠道。建议通过 MR 进行异步形式，并设定明确的截止日期：最长 24 小时审查。对于复杂的架构讨论，使用屏幕录制（Loom）。在分布式团队中，以书面形式在 MR 评论中记录决策尤为重要，这样上下文就不会因时区变化而丢失。