编程语言与软件工程2018sback.it

现代代码审查：Google 的案例研究

Modern Code Review: A Case Study at Google

入门 · 约 45 分钟读完前置知识：软件工程基础、代码评审流程的基本概念

302HN 得分

109条评论

2次投稿

导读

这篇 ICSE 2018 的论文通过 12 次访谈、44 人问卷以及对 900 万条代码评审记录的分析，研究 Google 内部代码评审的动机、实践流程、开发者满意度与挑战。论文称评审反馈很快：小改动中位数不到 1 小时，整体评审流程中位数不到 4 小时，并强调代码评审的核心目的是让代码能被他人理解、成为未来开发者的教材。

HN 关注点：HN 读者多为工程师，Google 的代码评审流程常被视为业界标杆，但多位亲历者对论文中“评审很快”的数据提出强烈质疑，讨论焦点是理想化研究与真实工作体验的落差。

关键词　代码评审Google软件工程静态分析

HN 评论精选

这几条评论里：质疑 1　补充 2　亲历 3

亲历亲历者质疑论文的评审速度数据，怀疑被自动生成的变更扭曲，但整体仍认可该流程的价值

我 2014-2018 在 Google 工作，对这些数字非常怀疑。基于我在三个团队的经历以及向许多外部团队提交变更的经验，小改动（<50 行）更可能是 3-4 小时，大变更（500+ 行）要 1-2 天。Google 有大量自动生成的 changelist，我怀疑这扭曲了数据——比如有人一口气点过 10 个自动生成的 CL 并全部批准，这些近乎即时的评审周期是否都被算进去了？不过我仍然很推崇 Google 的代码评审流程，虽然有人抱怨流程繁琐、获取 readability 认证麻烦，但我觉得这是在团队间传播知识、提升编程能力的好方式。

mtlynch查看英文原文

>In terms of speed, we find that developers have to wait for initial feedback on their change a median time of under an hour for small changes and about 5 hours for very large changes. The overall (all code sizes) median latency for the entire review process is under 4 hours I worked at Google from 2014-2018. I'm extremely skeptical of these numbers. Based on my experience working on three different teams and sending changelists to many other teams outside my own, I'd expect something more like 3-4 hours for small changes (<50 LOC) and 1-2 days for large changelists (500+ LOC). Google has so many automated changelists that I'm wondering if that skewed their numbers. Like if someone just clicks through 10 auto-generated CLs and approves them all, did that count for a bunch of near-instant review cycles? That said, I was a big fan of Google's code review process. I know people complained about the unnecessary level of process and the hassle of getting readability, but I found it all a great way to spread knowledge across teammates and improve programming skills.

亲历亲历者列举三种场景说明评审延迟严重、常被形式化甚至自我批准，与论文结论相悖

Xoogler（约 2014 年离职）。入职培训强调每个变更都必须经过代码评审，但我的实际体验是评审既沉重又令人沮丧，经常干脆被跳过——与论文所说的“数小时内反馈、快节奏迭代开发”完全不同。1) 我的搭档是固件工程师，不懂 Android，我只好去求关系不大的团队帮忙评审，反馈浅且慢，而项目受硬件排期约束。后来发现同事一直在给自己盖章批准（工具允许），我也照做了，绕过评审解决了问题。2) 下一个团队主要在东亚，时差导致每个问题都多两天延迟，异地同事也更倾向于搁置我的变更。3) 最后在富士康产线上盯构建时，硬件行为异常需要立刻改代码，评审在这种场景下根本行不通……

ridiculous_fish查看英文原文

Xoogler here, circa 2014. Noogler orientation impressed upon us that every change was code reviewed, period! However my experience was that code reviews were heavyweight and frustrating, often to the point of just being skipped: completely different from the article's observation of latency in hours and "fast-paced iterative development." 1. My initial team was a firmware engineer, and myself doing Android development. My peer felt unqualified to review Android code, so I spent a lot of energy begging code review time from tangentially related teams. Their feedback was not deep or useful for obvious reasons, and the days of latency posed a major problem because our project was tied to a hardware schedule. I learned later my teammate was simply stamping his own changes, which the tool permits, and so I started doing the same. Bypassing code review resolved the problem. 2. My next team was mostly in East Asia, while I was in Mountain View. If they had a question on a change, it would add two days latency due to time zone differences. And because I was physically detached from my peers, I believe they felt more comfortable deferring my changes. Again we were tied to a hardware schedule, so this latency was very painful. 3. The last scenario was overseeing builds, on (say) a Foxconn factory floor. For every build, the hardware coming off the line would behave unexpectedly, and we would have to very quickly update some code to make things work. Code reviews in this situation would have been absurd: any changes only had to last as long as the build itself, and well, there wasn't even network access. This is admittedly an exotic and specialized scenario (but recall orientation's "every change, period!") As a Googler code reviews were either skipped or were a major burden. I made some mistakes: I ought to have escalated quicker, increased my visibility, been less cowed by the orientation. Google also could improve in some areas: 1. Code review expectations need to be adjusted for small heterogenous teams. Such teams are more likely as Google ramps up its hardware efforts. 2. The engineering culture ought to recognize the burden imposed by time zones. Code reviews must be more forgiving when the communication cost is high. 3. Shift orientation towards teams instead of company-wide. CR for self-driving cars must be fundamentally different than CR for matching selfies with famous artwork, or CRs for updating factory floor test fixtures. Some of these may have changed since I left and if so I'd love to hear how.

亲历与另一位评论者经历相似：找不到合适的评审人导致流程形同虚设

我 2015 年前后在 Google 工作，觉得代码评审流程非常糟糕。我写 JS，唯一的队友是固件工程师，他不愿意也没能力认真评审我的代码，我只好从其他团队东拼西凑找评审人。他们自然不会优先处理，耗时极久，而且因为不参与我的项目，只能给出局部风格意见。几个月后我才发现其他工程师都在自我评审：把自己加为评审人然后直接点合并，于是我也开始这么干。

OneMoreGoogler查看英文原文

I worked at Google circa 2015, and found the code review process to be actively terrible. I was writing JS, while my sole teammate was a firmware engineer. He was not willing or able to meaningfully review my code, so I had to try to scrounge random reviewers from other teams. They naturally de-prioritized it, so it took forever. And because they were not involved in my project, they would only have local stylistic feedback. Months in, I finally figured out that other engineers were just self-reviewing: you can add yourself as a reviewer and just click merge. So I started doing that too.

补充提醒评审的核心是可读性和知识传承，而非风格吹毛求疵

论文“起源”一节提到：引入代码评审的主要动因是迫使开发者写出其他开发者能看懂的代码，因为代码必须充当未来开发者的老师。这一点应始终放在评审者的首要位置。评审过程很容易退化成风格之争、寻找每个低效点的竞赛，或者把代码写得越来越“聪明”和简短。

colemorrison查看英文原文

In the "How it all started section" - > E explained that the main impetus behind the introduction of code review was to force developers to write code that other developers could understand; this was deemed important since code must act as a teacher for future developers. This should always be at the forefront of the code reviewer's mindset. It's quite easy for the review process to degenerate into a style argument, quest to find every inefficiency, or attempt to make code as "clever" and brief as possible.

补充补充 Google 自动化静态分析工具的实践，以及阻塞式检查被滥用的治理难题

撇开人工评审不谈，我在 Google 期间印象更深的是自动化预提交检查，尤其是静态分析。我写 Java 较多，Error Prone 很有用；还有一些由 Tricorder 运行的工具。另一个有趣的挑战是让某项检查成为阻塞式预提交的成本：有时检查给不出有用反馈或测试信号不佳，人们就会开始强制提交绕过它，顺带也跳过了其他检查。

joatmon-snoo查看英文原文

Putting the human code review aside, one of the things I've been more impressed by during my time at Google has been the automated presubmits, generally the static analysis ones. I do a lot of Java, so Error Prone (https://errorprone.info/bugpatterns) has been a useful one (cf https://errorprone.info/bugpattern/FormatString); we have some others that Tricorder runs but I can't seem to find public references to. One thing that's also an interesting challenge is the work it takes to make something a blocking presubmit: sometimes you don't get useful feedback from one, or maybe a test doesn't provide very good signal, and then people start force submitting to bypass the check because it's not providing utility, but in the process also skip other checks.

质疑批评代码评审的对抗性模式，主张用协作式结对开发替代

大多数代码评审最终变成了变味的结对/团队编程。其中掺杂大量自我，缓慢笨重、令人痛苦，而且隐喻本身就是错的——它像一排法官审讯孤立的被告，而不是团队协作完成工程产物。我最近和几位开发者一起把笔记本投到大屏幕上、坐在沙发上喝着咖啡协作开发，很愉快且产出高质量结果。而多年代码评审的经验告诉我：评审痛苦、昂贵、平庸。我希望随着软件“吃掉世界”，公司能意识到让单个开发者解决问题、再把方案提交给团队评审，既对员工不友善，也是坏生意。

pmcollins查看英文原文

Most code review ends up being pair/team programming gone horribly awry. There's a lot of ego involved, it's slow and cumbersome, it's emotionally painful, and the metaphor is wrong (a panel of judges inspecting a lone defendant rather than a team collaborating on an engineering artifact). I recently had the opportunity to work with other developers on a project by displaying a laptop onto a giant screen while we all sat on a couch and drank coffee: it was fun and we produced a high quality result. After years of code review, on the other hand, I can say that code review is painful, expensive, and mediocre. I'm hoping that as software 'eats the world' and provides ever more value to larger numbers of people, companies will realize that putting a single developer on an engineering problem, and having the solution be submitted for review to the rest of the team after the solution has been designed is both unkind to your employees and bad business.

历次讨论

2018Hacker News 讨论帖182 分 · 64 评
2021Hacker News 讨论帖120 分 · 45 评

HN 二十年，最值得读的论文。

朋友分享的书单

专题阅读路线

本周最多人读

我的书单

必读 30 篇

论文库

这些论文是怎么挑出来的

全量扫一遍

只留论文本身

写导读、译评论

现代代码审查：Google 的案例研究

导读

HN 评论精选

相关资源

历次讨论

同领域还值得读

Google 的软件工程（2017）

Peter Naur：编程作为理论构建 (1985)

SciPy 1.0：Python 科学计算的基础算法

Lisp 的历史（1979）

使用 NumPy 进行数组编程

打赏支持

关注向阳乔木