编程语言与软件工程2019arxiv.org
软件项目与英雄：从 GitHub 项目中学到的经验
Software Projects and Heroes: Lessons Learned from GitHub Projects
入门 · 约 45 分钟读完前置知识：开源协作基础、GitHub 工作流
导读
这篇论文分析了 1100 多个开源 GitHub 项目中的“英雄”现象：即 20% 的开发者贡献了 80% 以上代码的项目。研究发现这种贡献高度集中的模式在开源社区中普遍存在，并建议组织思考如何更好地发现和留住这些核心开发者。
HN 关注点：HN 读者围绕“英雄程序员”概念展开争论：这究竟是开源维护者的常态，还是可以推广到职业团队的“10x 程序员”证据。
HN 评论精选
这几条评论里：质疑 2 补充 1 亲历 1
质疑研究对象是开源维护者，结论不能推广到职业团队，“英雄”一词有误导性
所有把这项研究放到全职工作或传统“10x 程序员”语境下解读的评论者，都应该先读摘要：所谓“英雄”项目是指 80% 以上贡献来自 20% 开发者的项目。当然几乎每个 GitHub 项目都有这样的“英雄”——我们通常叫他们“维护者”。这项研究毫不意外，也完全不能推广到开发专有软件的职业团队。摘要中使用“英雄”一词极具误导性。
benkuhn查看英文原文
Everyone who's interpreting this in the context of full-time work / the traditional notion of "10x programmer" (i.e. ~every toplevel commenter) should read the abstract: > A "hero" project is one where 80% or more of the contributions are made by the 20% of the developers... We identify the heroes developer communities in 1100+ open source GitHub projects. (emphasis mine) Of course nearly every Github project is going to have heroes--we call them "maintainers." This study is totally unsurprising and totally non-generalizable to professional teams working on proprietary software. The use of the term "heroes" in the abstract is massively misleading and tendentious, IMO.
补充英雄是反馈循环的产物；项目应拆分成小模块，而不是依赖英雄
如果那 20% 的人离开，剩下的人会均等贡献，还是新的 20/80 比例会形成？这看起来像反馈循环：写得越多的人越有条件写得更多，“英雄”其实是一个浮动位置，取决于技能、投入时间和各种环境因素。我最近讨论过这个问题：把一群“英雄”组成一个团队，所有人都会比分散在不同团队时慢得多。我的结论是，小型独立项目能让开发者又快又可靠；如果项目划分得当，任何人都能按自己的水平做贡献；而大型复杂项目只有最初写代码的老人才高效。所以在寻找“英雄”之前，先想想你的项目是否划分得当，以及“英雄”离开时的风险。
kartan查看英文原文
> A "hero" project is one where 80% or more of the contributions are made by the 20% of the developers. If that 20% leave, the other 80% would contribute equally or the ration 20/80 will be preserved? This seams a feedback loop. Once a developer has written more code than others is in a better position to write even more. If that is the case "hero developer" is a floating position, depending so much on your skill and how much time you have been working in a project and other circumstances. > Organizationsshould reflect on better ways to find and retain more ofthese software heroes. I had this discussion recently. If you create a team of "heroes" all become way slower than when they were in different teams. My personal conclusion, and the way of working that I try to implement at work is that small independent projects allow for developers to be fast and reliable. If your project is correctly divided, anyone can contribute ( at their level of expertise). If you have a big complex projects then old-timers that created originally the code are the only ones that can work with it efficiently if no other developers make big changes (reducing the ability of other developers to contribute independently of their level of skill). So, before going in search of "heroes" think if your projects are correctly divided. And think about the risk that you create when a "hero developer" is needed and leaves.
亲历亲历印证：一个投入的核心开发者远胜大量平庸人手
我自己做过很多很多软件项目，这个结论 100% 准确。一个全神贯注、真正对项目有热情的优秀程序员，抵得上 20-50 个只是机械写代码、毫不上心的程序员。这就是为什么小型、有激情的创业团队能持续做出比大公司好得多的产品。
jackconnor查看英文原文
Having worked on many, many software projects myself, this is 100% accurate. One good programmer who is intensely focused and interested in a project is worth 20 - 50 (or more) programmers who are just code monkeying it without really giving a shit. This is why a small, passionate startup team can consistently build better products than large corporations. Much better products.
质疑所谓英雄只是小项目常态，协作开销才是真正原因
把这些开发者称为“英雄”很可笑。更简单的解释是：大多数项目规模小到一个人就能完成大部分工作，而小项目不太会严重失败。加上协作必然带来的额外开销，事情变慢、更易出错并不奇怪——只是到了一定规模，这个代价是值得的。而且我们不会把少数人完成的项目都叫英雄：书有作者，而不是“写作英雄”——没有编辑和其他参与者，那本书根本不会问世。
taeric查看英文原文
I find it silly they designate these as heroes. Seems simpler to say that most projects are small enough that a single person can do the majority of the work. Not shockingly, most smaller projects don't fail that heavily. Add in the extra work that collaboration necessarily brings to the table, and it isn't that shocking that things both slow down and get more error prone. At a certain size, though, this is worth the cost of admission. More, it isn't like we call all projects done by fewer individuals heroes. We have authors, not "writing heroes." And the author joke is meant to point out that the vast majority of what you read has a single person's name on it, but without the editors and other workers involved, that book would never have come about.
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2019Hacker News 讨论帖337 分 · 134 评
同领域还值得读
Google 的软件工程（2017）
Software Engineering at Google (2017)
介绍了 Google 的软件工程实践，包括其单一代码库（monorepo）、几乎全部开发在主干进行而非分支、代码审查、构建系统 Blaze、协议缓冲区等工具与流程，并讨论了频繁重…
编程语言与软件工程2017 · 1,127 分 · 465 评 · 引用 15入门 · 约 45 分钟编辑精选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 分钟编辑精选