编程语言与软件工程2017arxiv.org编辑精选
Google 的软件工程（2017）
Software Engineering at Google (2017)
入门 · 约 45 分钟读完前置知识：软件工程基础、版本控制基础
导读
这篇论文（arXiv 2017）介绍了 Google 的软件工程实践，包括其单一代码库（monorepo）、几乎全部开发在主干进行而非分支、代码审查、构建系统 Blaze、协议缓冲区等工具与流程，并讨论了频繁重写代码作为知识传递和建立代码归属感的手段。文中还提到著名的 20% 自由时间政策。
HN 关注点：Google 如何在超大规模代码库上协作开发，讨论焦点集中在主干开发如何做大改动、monorepo 的利弊，以及论文描述与内部实际（如 20% 时间、项目分配）是否相符。
后来怎么样
这篇论文系统公开了 Google 的工程实践（monorepo、主干开发、代码审查、Blaze 构建系统等），成为业界了解大规模软件工程的重要参考，monorepo 与主干开发模式随后被多家大型科技公司讨论和采纳，并衍生出《Software Engineering at Google》同名图书。
HN 评论精选
这几条评论里：质疑 2 补充 1 亲历 1
质疑质疑不建分支的主干开发如何支持大型协作改动
我不理解他们如何完成较大规模的协作改动。论文说几乎所有开发都在仓库主干上进行，而非分支。Googler Rachel Potvin 在关于单体代码库的演讲中说法更绝对：在 Google 为开发而建分支极其罕见，分支通常只用于发布。在我的世界里，做大改动时我们会建分支，等足够成熟再合并回主干，分支让我们能协作。按我的理解，Google 的模式要么放弃协作只让单个开发者做改动，要么用其他方式共享代码，要么把未完成的工作提交到主干并不断破坏主干。
weinzierl查看英文原文
What I don't understand is how they accomplish larger collaborative changes. The paper says: "Almost all development occurs at the 'head' of the repository, not on branches." Googler Rachel Potvin made an even stronger statement in her presentation about "The Motivation for a Monolithic Codebase" [1]: "Branching for development at Google is exceedingly rare [..]" In the related ACM paper she published with Josh Levenberg there is the statement that: "Development on branches is unusual and not well supported at Google, though branches are typically used for releases." I my world when we have to make a bigger change we create a branch and only merge it into the trunk when it is good enough to be integrated. The branch enables us to work on that change together. I don't understand how they do this at google. As far as I understand in their model they either have to - give up on collaboration and always have just a single developer work on a change. - share code by other means. - check in unfinished work to the trunk for collaboration and constantly break trunk. [1] https://youtu.be/W71BTkUbdqE?t=904 [2] https://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext#
补充追问 monorepo 下变更如何映射到具体产品的发布流程
让我困惑的是，改动通过审查合并后，实际发布到生产环境的是什么？如果 monorepo 里有五个不同产品，某天只有一个产品有合并，Blaze 是构建并发布全部五个，还是只发布被改动的产品（及其依赖者）？另外 canary 服务器仍用于测试吗？现实中可能存在运行着非常不同版本的一组 canary，它们之间有没有版本关联或约束？
stillworks查看英文原文
So, the thing that is still buzzing in my head now and not mentioned in the article (maybe I didn't read carefully enough), what actually gets released into prod after a change is reviewed and merged. If the monorep contains let's say five different products and in a day only one of them gets a merge, then Blaze still builds all five and all five are released (based on successful integration testing)? OR only releases the changed product (and any other ones which depended on the changed one) EDIT: Also, the "canary" server is still for testing ? There may exist practically a set of canaries running very different versions ? Is there any correlation or any version "roll-up" constraints between various canaries ?
亲历亲历者批评论文回避了岗位盲目分配和团队高流失问题
论文对我在 Google 工作时认为最糟糕的一面只字未提：盲目分配。除非你完全不在乎想做什么，否则加入 Google 就是把未来交给一伙人随机抽签决定你的岗位。我在那里的短暂时间里，被分到一个 7 人团队，每月流失一人，这是我见过最差的留存率，我 4 个月后就离开了。不过源代码管理和构建流程确实一流。尽管有各种福利和聪明人，Google 的整体留存率也只比 Amazon 长一个月左右，这是有原因的。
varelse查看英文原文
Not one word about what I consider the most toxic aspect of working at Google: blind allocation. Unless one absolutely does not care what one wishes to work on, joining Google is throwing your future into the Hogwarts hat of an ill-defined cabal of billionaires to pick your job at Google. Sometimes that works out, but most of the time you are allocated to whatever mission-critical project is currently leaking buttcheeks. In my brief time there, I was placed on a 7-person team that lost one person per month. That is the single worst retention rate I have ever seen. I left after 4 months for that and the realization that the powers-that-be were in denial about the coming impact of an emerging technology that they have since embraced a year or so after my departure. That said, the SCCS and the build process were top-notch. But there are good reasons why despite all the perks and smart people, Google's overall retention rate is barely a month longer than Amazon's. http://www.slate.com/blogs/business_insider/2013/07/28/turnover_rates_by_company_how_amazon_google_and_others_stack_up.html
质疑质疑 20% 时间政策在现实中已名存实亡
论文称工程师可以把最多 20% 的时间花在任何自选项目上而无需经理批准。据我和现任员工的交流，这现在是胡扯。你确实可以把 20% 花在别的事情上，但许多团队的文化是这样做会因产出减少而危及你的同行评审。有没有现任 Googler 每周真的花一天做完全无关的事，愿意出来说说？
hueving查看英文原文
>Engineers are permitted to spend up to 20% of their time working on any project of their choice, without needing approval from their manager or anyone else. From what I understand talking to current employees, this is now bullshit. You could spend 20% on other stuff, but the culture in many of the groups is such that you are putting your peer review at risk by doing so because of your reduced output. Any current Googlers that spend 1 day of every week working on something completely unrelated to their main job want to comment?
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2017Hacker News 讨论帖442 分 · 156 评
- 2019Hacker News 讨论帖685 分 · 309 评
同领域还值得读
Peter Naur：编程作为理论构建 (1985)
Peter Naur – Programming as Theory Building (1985)
Peter Naur 1985 年的经典论文《Programming as Theory Building》提出：编程的本质不是写代码或文档，而是在程序员头脑中构建对程序及其运行…
编程语言与软件工程2016 · 629 分 · 74 评入门 · 约 45 分钟编辑精选SciPy 1.0：Python 科学计算的基础算法
SciPy 1.0: fundamental algorithms for scientific computing in Python
这篇发表于 Nature Methods 的论文介绍了 SciPy 1.0——Python 科学计算生态的基石库，涵盖其核心算法模块（优化、积分、插值、线性代数等）、软件架构与社…
编程语言与软件工程2020 · 387 分 · 98 评入门 · 约 45 分钟编辑精选Lisp 的历史（1979）
History of Lisp (1979)
这是 Lisp 发明者 John McCarthy 于 1979 年为 HOPL（编程语言史）会议撰写的回顾文章，讲述 Lisp 的起源、设计动机与早期演进，文中也涉及 if 表…
编程语言与软件工程2018 · 352 分 · 44 评入门 · 约 45 分钟编辑精选使用 NumPy 进行数组编程
Array Programming with NumPy
这篇 Nature 文章介绍 NumPy 的数组编程模型及其在科学计算中的核心作用：以 ndarray 为中心，通过向量化操作让 Python 高效处理多维数组。
编程语言与软件工程2020 · 318 分 · 134 评入门 · 约 40 分钟编辑精选将 C 编译为安全 Rust：形式化方法
Compiling C to Safe Rust, Formalized
研究如何把 C 代码编译为安全的 Rust，并给出形式化方案。
编程语言与软件工程2024 · 291 分 · 157 评专业 · 约 90 分钟编辑精选