
## 阶段三：Code Review从里程碑变成日常（2008 — 2010s 后期）

起点标志：2008 年 GitHub 上线 Pull Request 功能，将代码审查民主化——任何规模团队、甚至个人开源项目都能零成本开展审查。

| 维度 | 特征 |
|------|------|
| 审查形式 | 轻量、持续、嵌入开发流程——PR 是审查的载体，审查是 PR 的标配 |
| 审查对象 | diff（变更差异），但配合 CI 自动化检查 |
| 核心目标 | 从"找 bug"扩展为知识共享 + 代码一致性 + 持续学习——Google 的研究表明现代审查的首要价值是知识传播而非缺陷检测 |
| 审查者角色 | 全员审查——不再是专职或指定审查者，任何团队成员都可以是审查者 |
| 代表工具 | GitHub PR（2008）、GitLab MR、Bitbucket PR |

关键转变：
从正式到轻量——没有固定角色、没有检查清单、没有正式会议，审查更像"对话"而非"检验"
从里程碑到持续——审查不再是阶段性的质量关卡，而是每次提交的日常实践
从人到人+CI——CI/CD 流水线承担了编译、测试、lint 的自动化检查，人工审查聚焦于语义级判断
从缺陷检测到知识共享——Google 2018 年发表的《Modern Code Review: A Case Study at Google》系统揭示了现代审查的多元价值：代码可读性、知识传播、跨团队一致性、新人培养

学术研究密集期：2010s 出现了大量现代代码审查的实证研究，核心发现包括：
审查的有效性更多取决于变更规模（越小越好）而非审查者数量
审查者的主要贡献不是找 bug（实际找到的 bug 比例不高），而是改善代码可维护性和传播知识
审查延迟是最大痛点——PR 等待审查的时间直接影响开发效率

![image.png](https://developer.qcloudimg.com/http-save/yehe-11563618/88611bcb56a661eda2f077813a7f0b47.png)

## 开源文化对商业团队的渗透

代码审查曾经是企业内部的封闭流程——谁审、怎么审、审完归档，全在墙内完成。但开源社区从 1990 年代起就在用另一种方式做事：公开讨论、任何人可参与、靠说服而非指令达成共识。这条文化链最终倒灌进了商业团队。

**起点是 Linux 内核邮件列表。** 没有 UI、没有按钮、没有"Approve"权限位。一个补丁发到列表，维护者和其他贡献者回复邮件逐行讨论，达成共识后合入。它的审查模型是纯文本、异步、完全公开、靠声誉驱动——你提的反馈质量高，你的话语权就大。这套机制运行了二十多年，证明了"无强制权威的分布式审查"是可行的。

**GitHub 把这套文化产品化了。** Pull Request 本质上是邮件列表的 UI 封装：diff 视图替代了 `git diff` 粘贴、行级评论替代了邮件回复中的引用块、`@mention` 替代了邮件 CC。但它做了一件邮件列表做不到的事——把审查变成了社交行为。你的审查历史是公开的，你的评论可以被点赞，你的参与可以被看见。审查从"职责"变成了"影响力"。

**然后商业团队开始接受它。** 早期企业用 Git 大多是集中式工作流——每人直接 push 到主干，或者走内部的 Gerrit 实例，审查是"管控手段"。GitLab、Bitbucket 进入企业后，"@一下同事来审"变成了日常动作。审查不再是安全部门的合规检查，而是开发者之间的正常协作。开源社区的默认假设——"代码应该被同行看过再合入"——变成了商业团队的共同常识。

这条迁移链的核心不是工具传播，是**信任模型的转移**：从"上级审批"到"同行共识"，从"封闭管控"到"公开透明"，从"合规要求"到"文化习惯"。



## 审查者身份转变 & 被审查者心理转变

**审查者：从"守门人"到"协作者"**

PR 模型把审查权限从专职 QC 手里解放出来，变成一种临时角色——你今天审别人，明天别人审你。权力结构被拉平，初级工程师也能挑战高级工程师的代码，而异步文本形式降低了"当面质疑"的心理门槛。审查动机也从"防止出错"转为"共担责任"——你 approve 了，这段代码你也有份。

**被审查者：从"被审判"到"被帮助"**

传统审查会议把代码投到大屏幕上逐行过，天然触发防御心理。PR 的异步文本通道去掉了观众效应，心理安全感显著提升。但文本缺少语气，同样一句"这个命名不太清楚"在不同人读来可能是建议也可能是否定——措辞方式直接决定反馈是否被接受。

另一个被忽视的现象是"LGTM 文化"：审查太细反而被视作难搞，团队又不为严格审查提供正向激励，于是 LGTM 成了所有人的舒适区。打破它不需要换工具，需要管理者传递信号——好的审查反馈本身就是值得认可的工程产出。

新人参与审查则有特殊价值：他们问出的"蠢问题"往往暴露了代码可读性的真实短板，因为老人对代码库的隐含假设已经不自知了。


## 没有 GitHub 的团队怎么做轻量审查？

轻量审查的本质不是某个工具，而是三个条件：**变更可见、反馈可达、状态可追踪**。满足这三点，形态随意。

- **Gerrit / Phabricator**：企业自建方案，diff 视图 + 行级评论 + 异步讨论，体验与 PR 一致
- **邮件列表 + diff**：Linux 内核的做法，`git format-patch` 发到列表，回复邮件讨论。原始但有效——公开、可搜索、任何人可参与
- **共享分支 + 结对过 diff**：没有审查工具的团队，`git diff` 生成差异拉同事一起看，面对面或贴文档都行。唯一硬约束：**单次变更控制在 200–400 行以内**
- **聊天工具截图确认**：最弱形式，但比没有强一个数量级

比工具更重要的事：变更要小（审查效果的天花板由规模决定，不是工具）、管理者要示范（亲自审、亲自写详细反馈、被指出问题时说谢谢）、从小范围开始试行。



起点标志：2008 年 GitHub 上线 Pull Request 功能，将代码审查民主化——任何规模团队、甚至个人开源项目都能零成本开展审查。

【CR04】第三代代码审查技术 & 评审文化转变

起点标志：2008 年 GitHub 上线 Pull Request 功能，将代码审查民主化。

编程语言

开发工具

职业发展

阶段三：Code Review从正式流程演变为日常实践，以GitHub PR为核心工具，强调轻量持续审查、全员参与及知识共享。核心价值从缺陷检测转向团队学习，辅以CI自动化，并受开源文化影响，形成“同行共识”的信任模型。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

【CR04】第三代代码审查技术 & 评审文化转变-腾讯云开发者社区-腾讯云

【CR04】第三代代码审查技术 & 评审文化转变

【CR04】第三代代码审查技术 & 评审文化转变

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐