代码评审流程:从新团队到成熟团队

代码评审最常见的两个痛点:Lead/TD 把太多时间耗在评审上,而资深工程师评审参与不够;同时每个评审人的职责边界不清。解决这两点,关键不是「让大家多评审」,而是按团队所处阶段设计不同的评审流程——新团队和成熟团队要的东西不一样。

项目启动时先定三件事

• 职责表:每个功能模块谁是第一评审人、谁是第二评审人,写清楚。
• 评审沟通频道:专门的 channel 收发评审请求和讨论,别散落在各处。
• 编码规范:评审有客观依据,避免吵主观偏好。

新团队:两轮评审

团队还在「组建期 / 磨合期」时,用两轮评审。它的目的不只是把关质量,更是借评审过程把整个团队的评审能力带起来。

职责表长这样,每个模块配第一、第二两个评审人:

模块	第一评审人	第二评审人
Input	资深 A	Lead / TD A
Save	资深 B	Lead B
Graphic	资深 A	Lead / TD B
…	…	…

规则:

• 第一评审人是资深工程师,作为独立负责人先评。
• 必须第一评审人批准后,第二评审人才介入——别两个人同时评,那样意见会打架且浪费资深的把关价值。
• 第二评审人是 Lead/TD,做最后一道关。
• 评审请求通过团队频道通知到人。

流程:

成熟团队:一轮评审

团队进入「高效期(Performing)」后,职责要逐步收敛,评审也该更高效——降到一轮:

模块	评审人
Input	资深 A
Save	资深 B
Graphic	Lead A
…	…

规则:

• 只评一轮,资深工程师可以作为唯一评审人。
• 把 Lead、尤其是 TD 从大部分日常评审里解放出来,让他们专注更高杠杆的事。

这套演进的核心判断:两轮评审是新团队的培养成本,不是常态。一旦资深们的评审水准稳定了,继续保留双轮就是在浪费 Lead/TD 的时间——该砍就砍。

---

评审工具配置

评审流程要落到具体工具上。无论用哪套,有一条铁律:代码评审完成前,绝对不要把改动 push 到服务器——很多系统会因为改动入库而自动关闭关联的评审。

P4 depot:P4V 集成

P4V 配好评审插件后,在 Pending 视图里选中一个 changelist 或文件,右键就有「Create code review / Update code review」:

• 对整个 changelist 发评审,用 "Create code review (CHANGELIST)"。
• 如果 changelist 里夹了二进制文件,想只评其中部分文件,用 "Create code review (FILELIST)"。

P4 体系下也可以用 P4 Swarm 做评审看板。

Git / Hg:arc 命令行(Phabricator)

注:Phabricator 已于 2021 年停止官方维护,新项目不建议再上;这里作为一种「push 前评审」工作流的参考保留。

基本流程:

1. 在仓库根目录建 .arcconfig,指向评审服务器,并纳入版本管理:

   { "phabricator.uri" : "http://<your-review-server>/" }
   

2. 安装证书:arc install-certificate,按提示完成。

3. 创建评审:arc diff。arc 会问几个问题、打开编辑器让你填信息:

   • 有未跟踪文件时,问是否忽略并继续(输 y)。
   • 有未提交改动时,问是否新建 commit(输 y,arc 帮你提交)。
   • 然后填 Summary、Test Plan、Reviewers、Subscribers——其中只有 Subscribers 可省。

Test Plan 必填,要写清这次改动怎么测/怎么验;Reviewers 不能填成你自己。保存退出编辑器,看到评审创建成功的提示即可,评审人会收到邮件通知。