代码英雄讲述了开发人员、程序员、黑客、极客和开源反叛者如何彻底改变技术前景的真实史诗。

什么是《代码英雄》

代码英雄 Command Line Heroes 是世界领先的企业开源软件解决方案供应商红帽（Red Hat）精心制作的原创音频播客，讲述开发人员、程序员、黑客、极客和开源反叛者如何彻底改变技术前景的真实史诗。该音频博客邀请到了谷歌、NASA 等重量级企业的众多技术大牛共同讲述开源、操作系统、容器、DevOps、混合云等发展过程中的动人故事。

本文是《代码英雄》系列播客第二季（4）：更好的失败的音频脚本。

导语：失败是探索时的心跳。我们会在尝试新事物时会多次跌倒。其中秘诀是放弃快速失败，取而代之的是，更好地失败。

本期节目关注在科技领域如何拥抱失败。（对于科技领域来说）以好奇和开放的态度来对待失败是过程中的一部分。Jennifer Petoff 分享了 Google 是如何建立起一种从失败中学习和改进的文化；Jessica Rudder 通过视角的转变，展示了拥抱错误如何能带来意想不到的成功。而 Jen Krieger 则介绍了敏捷框架如何帮助我们为失败做计划。

失败未必是终点。它可以是迈向更伟大事物中的一步。

00:00:00 - Saron Yitbarek：

如果你没有听过这个笑话 —— 两个工程师在编译他们的代码。新手举手喊道：“哇，我的代码编译好了！”；老手则会眯着眼睛喃喃道：“唔，我的代码居然编译好了”。

00:00:18：

如果你已经做过一段时间编程，当你开始思考失败这件事，对有些事情的看法可能就会有所不同。那些过去无法解决的问题，如今开始看起来像一个更大的解决方案中的一个正常组成部分。那些你曾经称之为“失败”的东西，现在看起来像是变相的成功。

你开始希望你的代码无法通过编译。你希望可以一路摆弄和实验它们，调试和修订和重构这些代码。

00:00:37：

你正在收听的是红帽公司的原创播客节目《代码英雄》。我是主持人 Saron Yitbarek。

老实说，那句“ 快速失败 fail fast ”的口号经常被用来作为通往成功的捷径。但是，如果我们不是告诉彼此加快速度并快速失败，而是鼓励彼此更好地失败呢？

00:01:20：

《代码英雄》的第二季将介绍的是开发工作中真实的体验：“当我们生活在代码中，到底感觉如何？又是如何变化的？这也是为什么我们要用一整集的时间来讨论失败，因为正是这些失败时刻促使我们适应它。我们称之为“失败”的东西，是进化的心跳，而开源开发者正在拥抱这种进化。当然，这说起来容易做起来难。

00:01:59：

想象一下，如果一首全新的莎士比亚的十四行诗被发现了。网络上会兴起一阵热潮，每个人都想去搜索它。但这时，有个小小的设计缺陷导致了所谓的“文件描述符耗尽”。这会造成一连串的失败。突然之间，这所有的流量都在越来越少的服务器之间流动。很快，在 Google 上的“莎士比亚”搜索崩溃了，并崩溃了一个多小时。

00:02:33：

现在，你丢掉了 12 亿次搜索查询。这是一场莎士比亚式的悲剧，所有的一切，在网站可靠性工程师（SRE）四处补救的同时上演。

00:02:45 - 配音：

还有你吗，布鲁特？那就倒下吧，凯撒！

00:02:54 - Saron Yitbarek：

不好意思，我打断一下。但上面说的这个莎士比亚事件其实并不存在。事实上，这是一本书《SRE：Google 运维解密》中一系列灾难性场景的一部分。从这本书中学到的重要的一课就是你必须超越灾难本身。这就是我的意思。

00:03:13：

在这个莎士比亚的例子中，当流量被集火到一个被牺牲的单独集群时，这个死亡查询问题就解决了。这为团队赢得了扩充容量的足够时间。但你不能就此止步。尽管这个问题很糟糕，但解决它并不是真正的重点所在。因为失败不一定以痛苦告终，失败也可以引导你的学习。

00:03:38 - Jennifer Petoff：

嗨，我是 Jennifer Petoff。

00:03:41 - Saron Yitbarek：

Jennifer 在谷歌工作。她是 SRE（ 站点可靠性工程 site reliability engineering ）团队的高级项目经理，领导谷歌的全球 SRE 教育计划，她也是这本描述了莎士比亚场景的书的作者之一。对于 Jennifer 来说，钻研这样的灾难才能使事情变得更好，但前提是你需要有一个拥抱错误和意外的文化。

00:04:08：

所以，让我们再拿莎士比亚举例子。有一个直接的办法，减少负载可以让你免于这种连锁故障。但，真正的工作将在一切恢复正常之后开始，重点在于事后分析报告。

00:04:25 - Jennifer Petoff：

事件解决后，我们会创建一个事后分析报告。谷歌的每一个事件都需要有一个事后分析和相应的行动项目，以防止将来再次出现问题，以及更有效地检测和缓解未来出现类似事件或整类问题的可能。

00:04:42 - Saron Yitbarek：

这是一个关键的区别。不仅仅是解决这个特定事件，而是看到这个事件告诉你的一系列问题。真正有效的事后分析，不只是告诉你昨天哪里出现了问题。而是让你对今天所做的工作以及对未来的计划有深刻的见解。这种更广泛的思想，灌输了对所有这些事故和失败的尊重，使它们成为日常工作生活中至关重要的一部分。

00:05:12 - Jennifer Petoff：

所以，一个真正好的事后分析不仅仅要解决手头的单个问题，它还解决了整个问题。事后分析的重点是什么地方作对了，什么地方做错了，在何处幸运的解决了问题，以及可以采取哪些优先行动来确保这种情况不会再次发生。如果你不采取行动，历史必将重演。

00:05:32 - Saron Yitbarek：

在谷歌，人们关注的是 无责任的事后分析 blameless post-mortems ，这就造成了根本的不同。如果出了问题而没有人要责怪，那么每个人都可以诚实地挖掘错误，真正地从错误中吸取教训，而不必掩盖任何线索，也不必争吵。这些无责任的事后分析已经成为谷歌文化的一个重要组成部分，其结果是一个不必害怕失败的工作场所。这是一种正常情况。

00:06:01 - Jennifer Petoff：

谷歌如何看待失败？100% 的在线时间是一个不可能的目标。如果你认为这是可以实现的，那就是在自欺欺人。所以，失败会发生只是时间和方式的问题。在谷歌，失败是值得庆祝的，因为我们可以从中吸取教训，而事后分析也会在团队中广泛分享，以确保学到的东西可以广泛使用。

00:06:23 - Jennifer Petoff：

错误是不可避免的，但你永远不想以同样的方式失败两次。犯错是人之常情，但反复犯错是可以避免的。

00:06:34 - Saron Yitbarek：

听到 Jennifer 讨论失败的方式，这真是太有趣了，因为就像她在犯那些错误一样。比如，当事情出错的时候，这意味着你已经走到了一个可以挖掘价值的地方。

00:06:50 - Jennifer Petoff：

你会现场处理这种情况，但事后花时间把发生的事情写出来，让别人可以从中学习。发生任何事件时，你都需要付出代价。如果你不写出事后分析，并真正从这个经验中吸取教训，你就不会重新收回解决问题所花费的成本。在我看来，这是至关重要的一课。在谷歌，我们坚信无责任文化。你不会因为指责别人而获得任何好处，那只会让人们去掩盖失败，而失败，总是会发生。

00:07:27 - Saron Yitbarek：

这里非常重要的一点是，要记住 Jennifer 之前说过的一些话，没有错误的工作是一种幻想，总会有出错的地方。归根结底这是思想的转变。我们可以抛弃那种认为只有一个单一的、可确定的最终目标，即一切最终都会按照我们想象的方式发展的想法。我们没有人试图达到这一目标，事实证明，这是非常强大和积极的东西。

谷歌拥抱失败的做法很有意义。超级实用。但我想知道，这只是口头上的么？我们是否有一些具体的让事情变得更好的失败例子，或者这只是一种当我们进行第 200 次编译时，让我们感觉更好的一种方法。

00:08:26：

事实证明，有人可以回答这个问题。

00:08:29 - Jessica Rudder：

我的名字叫 Jessica Rudder。我是 Github 的软件工程师。

00:08:33 - Saron Yitbarek：

Jessica 在 Github 经历过失败。从某种意义上说，这是一个失败的舞台，在这一过程中，她收集了一些关于失败是通往巨大成功的故事。比如这个：

00:08:50 - Jessica Rudder：

90 年代有个游戏开发公司正在开发一款全新的游戏。从本质上说，这是一款赛车游戏，但他们的转折之处在于将其改为街头赛车。所以当赛车手在街道上飙车时，他们不仅是在互相飙车，而且他们也是与在追赶他们的警车（非玩家角色）赛车。如果一辆警车抓住了你，它会让你靠边停车，然后你就输掉了比赛。然后他们把这些代码衔接起来，然后开始运行，他们发现他们完全调校错了算法：警车只是尖叫着从侧街冲出来，直接撞向玩家的车，而不是追赶玩家的车。

00:09:37：

所以这里简直是一团糟。他们想，不要惊慌，让我们继续前进，看看人们如何看待它的，这样我们就知道该怎么调整算法了。所以他们把它交给了游戏测试人员，他们发现游戏测试人员在逃离警察并试图躲避被这些流氓暴力警车抓捕的过程中获得了更多乐趣。而事实上，它是如此的有趣，以至于开发团队改变了他们为游戏打造的整个理念。

00:10:17 - Saron Yitbarek：

你能猜出这是怎么回事吗？

00:10:21 - Jessica Rudder：

所以我们才有了《 侠盗猎车手 Grand Theft Auto 》。我的意思是，它确实是有史以来最畅销的电子游戏，它能存在的全部原因都是因为当时他们没有使用正确的算法时所导致的失误，他们想，好吧，让我们来试试；看看我们得到了什么，看看我们能从中学到什么。

00:10:41 - Saron Yitbarek：

很神奇吧？但这里有个技巧，《侠盗猎车手》团队在遭遇失败时必须保持宽容；他们必须保持好奇心。

00:10:52 - Jessica Rudder：

所以，如果这些开发者没有开放的思想，并决定从这个错误中去学到什么，我们将永远不会有《侠盗猎车手》，我们只能玩一些无聊的、普通的街头赛车游戏了。

00:11:07 - Saron Yitbarek：

让我们再就游戏主题讨论一分钟，类似的事情也发生在《 寂静岭 Silent Hill 》的制作过程中。这是一个大型的、3A 级的大制作游戏。但他们遇到了严重的弹出问题。局部景观的处理速度不够快，因此突然之间，你会突然发现一堵墙或一条小路突然冒出来。这是一个破坏性的问题，而且他们的开发已经到非常后期。他们是怎么做的？完全放弃游戏，举手投降？还是将错就错。

00:11:42 - Jessica Rudder：

他们所做的就是让这个世界充满了非常浓郁、诡异的雾气。因为事实证明，雾对处理器来说非常容易渲染，而且不会有任何延迟。而且另外，雾使你看不到远处的东西，所以在现实中，那些建筑物仍然会突然出现，但由于雾遮挡了你的视线，你看不到它们。所以当它们进入视野时，它们已经被渲染了，看起来它们是从雾中出来的。

00:12:15 - Saron Yitbarek：

雾是变得如此受欢迎，它基本上被认为是《寂静岭》系列中的一个特点。它限制了玩家的视野，使游戏变得更加恐怖。甚至当处理器的速度快到不需要再掩盖那些弹出的时候，他们也保留了雾气。

00:12:33 - Jessica Rudder：

你无法在没有雾的情况下玩《寂静岭》。而这些雾最初所做的一切都是在掩盖一个错误。

00:12:40 - Saron Yitbarek：

我喜欢这个故事！他们拥抱失败而不是逃避失败，从而挽救了一个重大的发展。这条关于不怕失败的原则也适用于个人的小事，而不仅仅是全公司的决策。从容面对失败是我们一点一点地变得更好的方法。

00:13:01 - Jessica Rudder：

很多时候人们脑子里想的太多了，他们认为失败意味着我不擅长某样东西。并不是代码坏了我还不知道如何修复它，而是“我不知道如何编写 JavaScript”。而且，你永远不会通过说“我不知道如何编写 JavaScript”来学习所需的知识。但是如果你能确定，“哦，我不知道如何在 JavaScript 中实现这个循环”，那么你可以通过 Google 找到答案，而且效果很好。我是说，你仍然需要努力，但你遇到的麻烦会少的多。

00:13:36 - Saron Yitbarek：

因此，无论你是新开发人员还是大型工作室的负责人，我们的错误将我们推向更大的领域，那些实验，那些失败，那些英勇的尝试，它们占据了旅程的大部分。在我所熟悉和喜爱的开源社区里，这是最真实的情况了。失败在开源中可能是一件美好的事情，这就是我们接下来的故事。

00:14:14：

我们在前面看到了失败是如何带来惊喜 —— 那些我们甚至不知道自己想尝试的事情。在最好的情况下，开源开发文化正好符合这一点。它让失败变得正常。为了理解这种愿意失败的想法是如何被引入开源开发的，我和 Jen Krieger 聊了聊。她是 Red Hat 的首席敏捷架构师。我们讨论了对开源失败的态度，以及这些态度是如何塑造无限可能的。请听：

00:14:47：

我想谈谈这个口号，我觉得这也许是一个很好的表达方式。“ 快速失败，打破现状 fail fast and break things ”，这几乎是为我们社区所设计的一个巨大的召集口号。你怎么看？

00:15:04 - Jen Krieger：

我对此有很多想法。

00:15:06 - Saron Yitbarek：

我也觉得你会有。

00:15:06 - Jen Krieger：

快速失败，在失败中前进，所有这些都是一个意思。所以，在我刚刚参加工作的时候，我在一家没有失败空间的公司工作。如果你做错了什么事情，你就可以准备辞职了。任何人都不能做错事，没有任何空间、途径允许你犯错。这令人们困扰。你绝对没有失败的余地，导致我们几乎陷入一场文化运动。愿意的话，这会催生出一个很棒词 —— 敏捷，以及催生出另一个很棒的词 —— DevOps。当我看到这些词的时候，我看到的是我们只是要求团队做一系列非常小的实验，帮助他们修正方向。

00:16:02：

这是个，哦，你已经做出了选择，而这实际上是一件积极的事情。你可能会做一个冒险的决定，然后你赢了，因为你做出了正确的决定。或者反之，就是你做了错误的决定，然后你明白了，那不是正确的方向。

00:16:18 - Saron Yitbarek：

是的，这是有道理的。所以，当你把“快速失败，打破现状”当成这个运动的时候，感觉在如何失败，如何以正确的方式失败上还是有一些方式，有一些最佳的实践的。那么，如何以一种正确的方式失败，有哪些最佳实践和原则呢？

00:16:44 - Jen Krieger：

我总是喜欢告诉工程师，他们需要尽早和尽可能多地破坏构建。如果他们正在破坏他们的构建，并且他们意识到他们已经破坏了构建，他们在当下还有机会真正修复它。而这一切都围绕着“ 反馈循环 feedback loops ”这个概念，并确保你在工作中得到的反馈循环尽可能小。

00:17:08：

所以在开源开发中，我提交了一个补丁，然后有人说，“出于这九个原因，我不会接受你的补丁”，或者“我认为你的补丁很棒，继续吧”。或者，你提交了一个补丁，但是机器人告诉你它失败了，因为它没有正确构建。有各种不同类型的反馈。

00:17:25：

然后在开源开发中，你可能会遇到更长的反馈循环，你可能会说，“我想设计这个新功能，但我不确定所有的规则应该是什么。有人能帮我设计吗？”因此，你进入了一个漫长的过程，在这个过程中，你要进行长时间和详细的对话，而人们参与进来，提出最好的想法。

00:17:45：

所以有各种各样的反馈循环可以帮助你完成这个。

00:17:50 - Saron Yitbarek：

Jennifer 认为，每个公司的反馈循环看起来都不一样。它们是可定制的，人们可以使它们以 100 种不同的方式工作。但重点是，她甚至没有把它们称为失败或错误。她只是称它们为“反馈循环”。这是一个有机系统，这是一种思考整个过程的健康方式。

00:18:11：

与此同时，对这些小毛病的另外一种态度却产生了完全相反的效果。

00:18:18 - Jen Krieger：

有些组织所做的事情是完全错误的。

00:18:23 - Saron Yitbarek：

嗯是啊。

00:18:24 - Jen Krieger：

让你的领导团队（或者，在一个很高的层面上，比如组织）认为，羞辱做错事情的人，或者在绩效结果方面灌输恐惧；就像是，“如果你工作做得不好，就拿不到奖金”或者“如果你工作做得不好，我会把你列入绩效计划。”这些都是会产生敌意的事情。

00:18:50 - Saron Yitbarek：

她描述的是一个不正确的失败。不能接受失败就是失败。她也在呼应 Jennifer Petoff 的态度，对吧？就是我们在这集开头提到的那个无责任的事后分析？

00:19:07：

是的，这很有趣。就好像如果我们在如何一起工作上要求更严格一点，或者只是更用心，更有目的性的在一起工作，我们几乎就会被迫在失败中表现得更好。

00:19:23 - Jen Krieger：

是的。有一些公司已经学会了这一点，而且他们很久以前就学会了，丰田就是一个很好的例子，它接受了这种不断学习和改进的理念，这是我在其他公司很少看到的。就是这样一种想法，任何人在任何时候都可以指出某些东西不能正常工作。不管他们是谁，在公司的哪个级别。在他们的文化中，认为这是对的。这种持续学习和改进的环境，我想说，是一种领先的实践，这是我希望公司能够做到的事情，能够适应失败并允许它发生。

00:20:06 - Saron Yitbarek：

嗯，没错。

00:20:07 - Jen Krieger：

如果你问的是为什么事情进展不顺利，而不是指责或试图隐藏事情，或责怪别人，这就会造成完全不同的情况。那就是改变对话方式。

00:20:23 - Saron Yitbarek：

这很有趣，因为你之前提到过“快速失败，打破现状”这句话是这种文化，这种对过去做事方式的反击。 但这听起来似乎是一种口头禅，也许也创造了一种在公司内部、技术团队内部的不同的团队工作方式。再给我讲讲这个问题，它是如何改变了开发人员看待自己角色的方式，以及他们与公司其他人互动的方式?

00:20:55 - Jen Krieger：

我早期和工程师一起工作的时候差不多是这样的，工程师们都坐在一个小区域，他们互相交谈。他们从未真正与任何商业人士进行过交流。他们从来没有真正理解他们的任何需求，我们花了很多时间真正专注于成功所需的东西，而不一定是企业实际完成工作所需的东西。所以，它更像是，“我是一个工程师，我需要什么才能编写这个功能片段？”我观察到，今天在几乎每一个和我一起工作的团队中，对话方式已经发生了巨大的变化，“作为工程师我需要什么才能完成工作”变成了“客户是谁，或者用户需要什么才能真正感觉到这我做的这块功能对他们来说是成功的？他们如何使用产品？我该怎样做才能让他们更轻松？”

00:21:56：

很多这样的对话已经改变了，我认为这就是为什么如今公司在提供有意义的技术方面做得更好的原因。我还想说的是，我们发布的速度越快，我们就越容易知道我们的假设和决定是否真正实现了。所以，如果我们对用户可能想要什么做了假设，在此之前，我们需要等待，比如，一年到两年才能确定这是不是真的。

00:22:25：

而现在，如果你看看亚马逊或奈飞的模式，你会发现，他们每天会发布数百次假设的客户需求。他们从使用他们的应用程序的人们那里得到的反馈，会告诉他们他们是否在做用户需要他们做的事情。

00:22:46 - Saron Yitbarek：

是的，这听起来需要更多的合作，因为即使是你之前提出的关于构建、破坏构建、经常破坏它的建议，这就需要工程团队或开发人员与 DevOps 保持步调一致，以便他们能够破坏它，并了解尽早发布并经常发布是什么样子的。听起来这需要双方更多的合作。

00:23:15 - Jen Krieger：

是的，对于拥有敏捷教练这个头衔的人来说，或者以我作为首席敏捷架构师看来，总是很有趣，因为《敏捷宣言》的初衷是让人们从不同的角度来考虑这些事情。我们通过开发和帮助别人开发来发现更好的开发软件的方法。它确实是敏捷所要做的的核心、根本和基础。因此，如果你将 10 年，15 年以上的时间快速推进到 DevOps 的到来，并坚持我们需要持续进行集成和部署。我们有监控，我们开始以不同的方式思考如何将代码扔出墙外。

00:23:56：

所有这些东西都是我们最初开始讨论敏捷时应该想到的。

00:24:03 - Saron Yitbarek：

嗯。绝对是的。所以，不管人们如何实践这种失败的理念，我认为我们都可以接受失败，将失败规范化只是过程的一部分，是我们需要做的事情，是我们可以管理的事情，是我们可以用“正确的方式”做的事情，这是一件好事。它对开源有好处。跟我说说这个新运动的好处，这种接受失败是过程的一部分的新文化的一些好处。

00:24:36 - Jen Krieger：

看着这个过程发生是一件美妙的事情。对一个人来说，从一个他们害怕可能发生事情的环境，到一个他们可以尝试实验、尝试成长、尝试找出正确答案的环境。真的很高兴，就像它们已经盛开花朵。他们的士气提高了，他们真正意识到他们可以拥有的是什么，他们可以自己做决定，而不必等待别人为他们做决定。

00:25:05 - Saron Yitbarek：

失败即自由。啊，我喜欢! Jen Krieger 是红帽公司的首席敏捷架构师。

00:25:19：

并不是所有的开源项目都像 Rails、Django 或 Kubernetes 那样声名鹊起。事实上，大多数都没有。大多数都是只有一个贡献者的小项目，解决一小群开发人员面临的小问题的小众项目，或者它们已经被抛弃，很久没有人碰了。但它们仍然有价值。事实上，很多这样的项目仍然非常有用，可以被回收、升级，被其他项目蚕食。

00:25:54：

而另一些人通过他们的错误启发我们，教导我们。因为在一个健康的、开放的舞台上，失败会带给你比胜利更好的东西。它给了你洞察力。还有一点。尽管有那些死胡同，尽管有各种冒险的尝试和惊呼，但开源项目的数量每年都在翻倍；我们的社区正在繁荣，事实证明，尽管因失败我们没有繁荣，但因失败我们正在繁荣。

下一集预告，DevOps 世界中的安全性如何变化。持续部署意味着安全正在渗透到开发的每个阶段，这正在改变我们的工作方式。同时，如果你想了解更多关于开源文化的知识，以及我们如何改变围绕失败的文化，请访问 redhat.com/commandlineheroes ，免费资源等着你。

00:26:54 - Saron Yitbarek：

《代码英雄》是红帽的原创播客。你可以在 Apple Podcast、Google Podcast 或是其他你喜欢的途径免费收听。我是 Saron Yitbarek，坚持编程，下期再见。

什么是 LCTT SIG 和 LCTT LCRH SIG

LCTT SIG 是 LCTT 特别兴趣小组 Special Interest Group ，LCTT SIG 是针对特定领域、特定内容的翻译小组，翻译组成员将遵循 LCTT 流程和规范，参与翻译，并获得相应的奖励。LCRH SIG 是 LCTT 联合红帽（Red Hat）发起的 SIG，当前专注任务是《代码英雄》系列播客的脚本汉化，已有数十位贡献者加入。敬请每周三、周五期待经过我们精心翻译、校对和发布的译文。

欢迎加入 LCRH SIG 一同参与贡献，并领取红帽（Red Hat）和我们联合颁发的专属贡献者证书。

via: https://www.redhat.com/en/command-line-heroes/season-2/fail-better

作者：Red Hat 选题：bestony 译者：bestony 校对：wxy

本文由 LCRH 原创编译，Linux中国 荣誉推出

大约五年前的今天，我上交了 Google 员工证，然后走出了悉尼 Google 办公室，开启了一段自谋职业的崭新生活。我认为我应该详述一下这个故事，因为我通过阅读 Michael Lynch 的作品而收获颇丰。正如你所看到的，我仍然花费了几年时间才开始考虑写这篇文章，但是最终我告诉自己，倘若我不在五周年纪念日写它，我就永远也不会写了。

这篇文章有点儿长，但是我希望它对那些对于在大型技术公司工作感兴趣的新开发人员或是想要离职的大型企业雇员能够有所帮助。我将谈谈我进入 Google，在 Google 工作和辞职的故事，以及之后我做了什么。如果你想了解更多的细节，可以随时询问，不过我已经有很多博文要写，所以不能保证有什么深入的内容。

同样地，冒着显而易见的劳工风险：我已经有 5 年不在 Google 工作了，所以请不要以这个故事来作为当今 Google 或是 Google 雇员经历全貌的字面描述。但是，我认为其中的许多内容仍然与一般性的技术职业有关。

通往 Google 的艰辛道路

2005 年，我获得了第一份带薪的编程工作，是在当地的电力公司工作，把一些旧的 Pascal 代码用不同的编译器在不同的操作系统上运行。这基本上只是我为了挣外快而做的暑期工，同年我还刚刚开始攻读我数学和物理的学位。他们很高兴有一个本科生能够胜任这份工作。我被这些大人吓了一跳，因为他们不仅只是对我的编程爱好感兴趣，而且真的还会为此给我钱。

直到 2007 年毕业以前，我一直在做类似的工作。我喜欢编程工作，而 Google 是一家从事着很酷的编程工作的很酷的公司，因此我申请了实习。 Google 的面试过程以困难而著称，所以我花了好几个星期时间练习了所有我在网上能够找到的 Google 面试题。我认为 13 年里面试流程并没有发生太大的变化 —— 我提交了简历，受邀参加了几轮电话面试，这些面试问的几乎都是算法问题（我记得有一个动态规划问题和一个分治几何问题）。我通过了最初的几轮面试，然后受邀前往悉尼接受了由 Google 的工程师们进行的为期一天的现场面试。我回到家里，等待 Google HR 的电话，这个过程漫长得像是有一辈子。我被拒绝了。

对于我们收到的拒绝和失败感到难过很自然，因此我们并不会经常谈及它们。但是出于同样的原因，其他人也不会去谈论他们自己的失败，这只会使得情况变得更加糟糕。当我后来真的进入 Google 时，我觉得作为一个此前被拒绝过的人，我一定有哪里做得不对，但是有一天我和一群同事坐在一张桌子旁，开始交谈。那时候我才发现，实际上我身边的很多人都至少被拒绝过一次。我甚至都不是“最差的”。有个家伙开玩笑说，他肯定是因为 Google HR 厌倦了拒绝他才得以进来的。我说的也是一些相当厉害的工程师 —— 有些人负责着我一直在用的代码，而我打赌你也在用。

进行面试的公司通常会为每个名额面试两名或更多的候选人。这意味着比起录用，会有更多的拒绝，所以一般面试参与者被拒绝的可能性要大于被录用。然而我们一直忘记了这一点。四个开发人员参加面试，一个被录用了，其他三个在社交媒体上抱怨这场面试是如何的漏洞百出，因为他们个人被拒绝了。当然，面试远非完美，但是我们需要停止如此个人化地谈论它。

只要你能够找到问题所在并知道如何去改进自己，拒绝和失败就没有那么糟糕。Google 的面试主要针对算法，我在其中磕磕拌拌地摸索，但绝对没有能够脱颖而出。

在被 Google 拒绝以后，我得到了两样东西，并进行了为期一年的休假。第一件东西是澳大利亚商务编号（ABN），我用它来提供数学与科学补习课程，以及技术工作合同。我获得的另一样东西是一张大学科技图书馆的借书证。我当时并不打算再次去参加 Google 的面试，但是那次的面试经历告诉我还有很多东西是我所不知道的。我就在图书馆开设课程给大家做辅导，并在期间阅读书籍。顺便说一句，有些人认为我为我的补习业务所做的所有这些财务工作和其他东西很奇怪，而大多数补习老师都只收现金。但是我学到了许多对我日后生活很有帮助的东西，所以我一点儿都不后悔。

2009 年，我根据一个叫 Persi Diaconis 的魔术师转行为数学家的作品，进行了一个数学荣誉课程（也就是学士学位四年级）。计算机科学系让我选修他们的一个算法单元作为其中的一部分。

就像我所说的那样，我本来并没有打算再去 Google 面试，但是让我快速地讲讲这是怎么发生的。我从高中就开始学习日语，因此在 2012 年，我决定尝试在东京生活。这基本上行得通，除了我犯了一个相当大的错误 —— 我没有任何日语方面的纸质资质证明，因此很难获得工作面试。最终，我的一个已经被 Google 录用的朋友建议我再试一次。与 Google 所有的办事处一样， Google 东京的官方商务语言是英语，因此他们不要求我具有日语资质证明。

Google 面试，再一次

我的朋友向 Google HR 推荐了我。这绝对有帮助，但是如果你自己得到了被推荐的机会，也不要太过于兴奋。它所能够确保的是你的简历会被注意到（不是小事）并且免去一次电话面试，但你仍然得通过剩下的电话面试和现场面试。

这一次我用来自 Project Euler 和 Google CodeJam 的题进行练习。电话面试过程中，我不得不在 Google Doc 上进行一些在线编程，这有点儿尴尬，但是除此以外电话面试一切顺利。然后我受邀前往六本木的 Mori Tower 办公室进行了为期一天的现场面试。

我的首个面试非常糟糕。我的脑子僵住了。我知道我能够解出那些题目，但是直到面试官走出房间我才想出答案。我立刻就感到很放松，并且意识到这是一个三元搜索问题。这是在是很令人沮丧，但是我觉得继续前进，看看剩下的面试进展如何。

其中的两道面试题很糟糕。其中之一直至今日仍然是我遇到过的最糟糕的面试问题。面试官说：“你用同一输入运行一个程序两次，得到了两个不同的结果。告诉我这是为什么。”我回答道：“当这种情况在现代计算机上发生而且并不在我的预期之中时，通常是竞态条件。”他只说：“不，这不是竞态条件。”然后看着我等着我的下一个回答。如果他有兴趣讨论一下的话，这个问题本该是一个很棒的问题，但是很显然他实际上只想玩“猜猜神秘数”。对于我所说的几乎全部内容，他只是回答：“不。”显然，该程序完全是确定性的，不存储任何状态，并且不依赖于环境（例如磁盘或是实时时钟），但却在每次执行时都给出不同的结果。我怀疑我们对于“被存储的状态”或是“环境”的含义还是某些东西有着不同的理解，但是我无法区分。有一次（变得绝望了）我试着问电子元件的温度变化是否会有影响，而他说：“不，那会是一个竞态条件，我已经告诉过你这不是竞态条件了。”最终，面试结束了，而我仍然不知道那个秘密数字是什么。

我讲这个故事的原因是，我听说过许多更为平淡的恐怖故事，用以证明面试官是憎恶面试者的坏人。然而，与流行的刻板印象所相反的是，当天的大多数面试基本上都还可以，面试官也很友好并且很尊重人。面试也着实很困难，因此最好减少面试官的工作量。希望那个“猜数字”面试官从 Google HR 那里得到的反馈是，他的问题对于作出聘用决定没什么帮助。

这次，面试带来了一份要约，但是有一个小问题：这份工作在悉尼，担任站点可靠性工程师（SRE）。我以前从未听说过 SRE，但是我和一位悉尼的资深 SRE 通了电话，他解释说他注意到了我在天然气行业从事嵌入式工程的经历，并且认为 SRE 会和适合我，因为同样强调可靠性与拟合紧密约束。

在东京花了大约一年时间来建立起自己的生活，我不想抛弃一切然后搬到悉尼，但是我绝不可能会拒绝一份来自 Google 的要约。与招聘人员交谈时，我确实犯了一个非常愚蠢的错误：我被问到当时能赚多少钱，然后我就脱口而出。别这么做。这意味着不管在面试中发生了什么事情，或是你上一份工作中被底薪了多少，或者其它什么。你可能会被拒绝，或者会在原来的薪水基础上得到一些象征性的提升，并且如果你试图进一步协商，会被认为疯狂而又不合理。就我而言，我的收入甚至远远低于 Google 的入门级职位。我无法肯定地说全是这样，但是在 2013 年我搬到了悉尼，在 Google Maps 成为了一名新毕业生级别的 SRE。

悉尼的 Google Maps SRE

像 Maps 这样的产品实际上是若干个软件项目，每个都有自己的开发人员团队。甚至诸如路线查找之类的功能实际上也是多个软件项目 —— 从交通时刻表数据收集，到线路计算，再到结果渲染，等等等等。 SRE 的工作包含两个方面：一方面是为各个项目提供待命，实时响应任何生产事故；另一方面（在无需救火时）则是将生产事故中所积攒的经验应用到其他项目中去，并且发现其中可能出错的方式，或是发现使其性能更好的机会。Google 的 SRE 还需要像开发人员的内部咨询小组一样，对部署实践、自动化、监控或是类似的问题提供咨询。

这项工作相当紧张。作为一个团队，我们每周至少需要处理一次生产事故，否则就要为更多的服务提供支持。每个礼拜，悉尼的所有 SRE 都会聚在一起，交流发生过的故障事件或是有关如何使事情更好地运转的新技巧。学习曲线的感觉就像是再次成为了一名本科生。

我有时会感到震惊，听说我选择离开 Google 的人会问：“但是你不会想念那些福利吗？！”物质上的福利（例如伙食等等）绝对很棒，但是它们是你可以买到的东西，因此，不，它们不是我所想念的东西。如果你问我所想念的是什么，我会说是在那里工作的人们。与你可能听说过的不同，傲慢的人不喜欢在 Google 之类的地方工作。有一个臭名昭著的故事，一个自恋的人在 Google 找了份工作，并假装自己是各方面的顶级专家，让自己尴尬不已。他待了不到半年就离开了。总的来说，与我工作过的其他地方相比，这里的文化在傲慢、指责以及政治方面很少。另一方面，Google 并没有垄断好同事。

不过，有一种公司政治是个大问题。晋升需要“展示影响”，而众所周知的是，要做到这一点最简单的方法是发布一些新事物（不是惟一的方法，但是最简单）。结果是 Googler 们比起改进现有的解决方案，对于推广他们自己内测品质的原型方案更感兴趣。在 SRE 之间，我们经常开玩笑说， Google 内部有两种软件：一种是老的东西，工作得很好，但已经废弃了，甚至连考虑使用都是不够谷歌化的；另一种是热门的新东西，尽管它们还不能用，但却是今天 100% 可以使用的官方工具。作为 SRE，我们经常亲眼看到新的热点事物出了什么问题（有时甚至在没出 alpha 之前它就已经成了过时的旧东西）。（我此前已经对这类事物进行了更为深入的讨论。）

这不是我们这些愤世疾俗的 SRE 所想象的东西；这在公司中被公认为是一个问题，而我记得有人向我保证，晋升委员会已经开始通过维护工作等方式寻找关于其影响的证据。

晋升申请

2015 年，在 Google 工作了两年之后，我的经理告诉我，现在是时候申请一个高于我新毕业生水准的晋升了。晋升过程是每年两次由晋升委员会进行集中管理的。你可以先提出申请，然后加上一份对你所从事过的项目的简短描述，再加上同事的推荐信。委员会将会进行审查，然后给你赞成或反对的意见。仅仅有你经理的推荐是不够的，因为你的经理有想让你获得晋升的动机。手下有高级别的员工有助于你自己的职业发展。

长话短说，我提交了我的申请，而委员会说不。事实上，这是个相当糟糕的拒绝。我不记得详细的答复了，但感觉就像是委员会在我的申请中寻找可以不屑一顾的东西。例如，我从事过的一个项目是一个内部工具，它出现了功能需求的积压。我查看了这个项目，发现根本问题在于它已经超出了构建它的键值存储，需要一个合适的数据库。我主张切换到关系数据库，并实现了它：模式、数据迁移、查询、实时站点迁移等等。新查询的速度要快得多，而且（更重要的是）可以有效地支持新功能。在进行迁移之前，我必须要解决的一个问题是大部分代码没有被测试所覆盖，而这是由于大部分的代码都不可测试。我使用依赖注入以及我此前讨论过的其他技巧重构了代码，而这使我能够构建一组回归测试套件。我记得这个项目被驳回主要是被评价为测试单元的编写是“新毕业生水平的工作”。

我的经理真的很支持我，并且写了上诉。他没有给我看，但是我认为这是可以被缩减成 “WTF” 的若干页（更雄辩而详尽地论述）。以下是一些我也认为这一回复有点 “WTF” 的原因：

Google SRE 有一种“关键人物”的概念。一个项目的关键人物有两个角色：一个是比起其他 SRE 对于软件项目有着更为深入的了解，以便你能够回答他们可能会提出的问题；另一个角色是作为项目本身的开发人员的第一联络人，以便他们的所有 SRE 问题都能得到回答。 Google 的职业阶梯指南说，关键人物不应该处于“新毕业生水准”，而应该晋升。正如我在申请中所写的，我是三个项目的关键人物。

我的关键人物经历使得想要找到同意支持我的晋升申请的资深开发人员很容易。当他们发现我是新毕业生级别时都十分震惊。他们都同意支持我的申请，认可我已经处在了一个更高的级别。

在我的申请之中，我提到曾担任过一组新毕业实习生的导师。当我提出申请时，他们之中的许多人都已经被聘用为了正式雇员。我足够资深，可以去担任他们的导师，但是还绝不足以晋升到比他们更高的级别。

给我经理上诉的回复与最初的审查截然不同。这次，我“大大超出了对于我‘新毕业生’级别工作的期望”，但是问题在于他们需要稍多一些时间来确保我能够晋升到新毕业生加一的级别。我被告知在接下来的 6 个月时间里，倘若我能够继续超出预期，直到下一个晋升周期，也许那时我就会得到晋升。上诉结束了；这就是最终结果。

我写了一封电子邮件，表示我要采取另一种选择。就像许多科技公司一样， Google 也有员工持股计划。在开始工作时，你会得到一笔象征性的补助金，而在各个“投资”里程碑时刻，你会收到真正的股份。我的下一次股票授予是在几个月之后。从那以后，我将不再为 Google 工作。

我离开的原因

任何辞职的决定并不容易，而某天你或许会面临同样的抉择。以下是一些有助于我作出决定的因素。（我在以前的一篇贴子里对一些这类想法进行了更深入的解释。）

如果你思考一下，考虑到我并不是字面意义上真正的应届毕业生， Google 的评价应该是这样的：“你正在做一些非常错误的事情。在 X、 Y 还有 Z 方面有所改进之前，你根本不会得到晋升。”被告知“你远远超出了预期，但是我们还需要 6 个月左右的时间”，这是毫无道理的。没有人关注我是否有能力做好我的工作。我得到了许多借口，但是没有能够帮助我提高的任何有用反馈。（注意：有时候你必须要明确地要求反馈。经理们可能会陷入捍卫自己所给出的绩效评级的陷阱，而不会去考虑报告是否需要反馈。）

我也不确定晋升委员会会在 6 个月里看到什么他们在已经过去的 2 年时间里都没有看到的问题。他们难保不会再要求 6 个月时间？如果我需要花上多年时间来证明自己以获得新毕业生加一的级别晋升，那么我升到新毕业生加二的时候得有多老呢？

刚加入 Google 时，我的工作级别无关紧要，因为我当时学到了那么多东西，并且能在我的简历里写入一家著名的公司。两年过后，等式变得不同了。 Google 所提供给我的未来所具有的价值正在下降，而 Google 之外机会的价值却正在上升。 Google 的职位实际上在 Google 之外几乎毫无意义。在过去的 5 年间，许多人都问过我在 Google 做过什么，但是没有一个人问我在 Google 是什么职位，也没人称我为“新毕业生”。尽管我在短期内受到了财务方面的打击，但实际上在我上交员工证的那天我就已经得到了晋升。

值得称赞的是，Google 没有做过任何类似于以下的事情，但是在其他公司中却很常见：试图让员工对于要求加薪感到内疚。在几年前我工作过的地方，一些工程师在一次成功发布会后，在许多紧要关头要求加薪。管理层扮演起了受害者的角色，并且指责工程师们是在“强迫他们”。（大约 6 个月时间后，他们失去了自己大部分的工程团队。）如果你真的愿意就辞职时间进行配合（例如，在发布日期之后，而不是前一周），并且愿意记录下你的知识并做了整理等等，那么你仅仅是由于雇主支付给你的工资不足而“强迫他们”。

名义上，我在 Google 留下了大量未授予的股票。但是知道你拥有股票时，股票才属于你。我只是得到了未来会有分红的承诺，而我可以将其除以所需的时间来将其转换为同等的工资率。为这项投资工作 2 个月是值得的，为了剩余的投资工作数年是不值得的。不要被授予股票的偏见所迷惑。

什么时候不应该辞职呢？嗯，与在其他地方相比，你能得到的很多吗？公司的职业发展道路不是天上掉下来的，他们是一系列的业务报价，代表着你将为什么样的公司评估而工作。如果你认为自己能得到很多（考虑到所有的薪酬和像是工作环境之类的无形资产），很好！否则，是时候认真考虑一下下一步该做什么了。

离开 Google 之后

我应当警告你的是，我采取了高增长的战略，但是牺牲了短期稳定性。如果对你而言稳定性更为重要，你应该做出不一样的选择。我的 A 计划、 B 计划、 C 计划都失败了，我最终花费了几个月时间苦苦找寻出路。最后，我在一家小型网店得到了一份合同，为 Safety Town 工作，一家政府建立的面向孩子们的道路安全网站。那里的薪水较之于 Google 是一个巨大的缩减，尤其是考虑到这是我几个月以来的第一份工作。但是，你知道，我真的很享受这个项目。当然了，它不像 Google 那么“酷”，而且可能一些学校里的孩子也不觉得它酷。另一方面，在 Google，我只是机器中的一个螺丝钉。 Safety Town 有一个小团队，每个人都扮演着至关重要的角色。在 Safety Town 项目中，我是后端工程师， Safety Town 当时是我唯一需要费心的事情。而且可能一些孩子已经在这个网站上学到了一两件有关道路安全的事情。从那以后，我做了很多项目，大多数都更大，但是我仍然会向人们展示 Safety Town。

我记得 Google 悉尼办事处的一张海报，上面写着：“飞向月球吧！即使你错过了，你也会降落在群星之中！”人们很容易忘记，即使你不是在为知名公司或初创公司做“登月计划”，你也可以拥有高质量的生活。

这儿有一个帮助我获得合同的窍门。我会去参加悉尼的科技活动，站在能看到求职公告板的范围之中，等着看见有人在上面写东西。假设他们正在为一个保险公司项目写 CSS 开发方面的信息。即使我对 CSS 或保险不是特别感兴趣，我也会晃悠过去说：“嗨，这是个什么类型的保险项目？”这是最容易的开启谈话的方式，因为在他们努力往求职公告板上的狭小缝隙中写字的时候，满脑子都是这个项目。通常情况下，这样的谈话仍然不会为我带来一份工作，但是偶尔也会发现一些我能够帮上忙的东西。有些活动没有求职公告板，但是组织者们往往很乐意把麦克风递给别人几分钟。这为他们的活动增添了社区参与度。

我在做了一个政府采购的网站后，我取得了重大的突破，因为我学会了不至于对政府采购一窍不通。很难确切说出这些知识的价值，但是不到一年过后，我就签署了一份政府合同，比我此前所期望的要多了 40%。（不过，我如今没有做那么多的政府和大型企业的工作了。）

大约一年半过后，我有了自己的一人公司。随着我声誉的建立，我逐渐获得了更多类似于 SRE 的工作。基本上，从事开发工作是我的“工作”，然后几个月后就有一个需要 SRE/DevOps 帮助的人联系了我。我事实上既喜欢 SRE，也喜欢纯开发工作，但是供求关系意味着 SRE 工作是个好工作。我仍然可以在空余时间编程。

说起这个，工作与生活的平衡是我在新生活中最喜欢的事情。没有人在两份合同之间给我酬劳，但是我可以通过在业余项目中学习新东西来充分利用这一间隙。在一个漫长而又紧张的合同之后，我休息了一下，进行了为期一个月的背包徒步旅行，探索了日本乡村。这是我期待了很长时间的一次旅行，但是在入职 Google 之前我需要更多的钱，而在 Google 供职期间我又需要更多的时间。自营职业远非没有压力，也不是适合每一个人的，但是有的压力会让你感到死气沉沉，有的压力则会让你越发充满活力。于我而言，自主营生是第二种，我想说，和在 Google 时相比，过去的 5 年间我的压力总体上有所减轻。对于我来说，至少我能够诚实地说我不后悔当初加入 Google，也不后悔当初离开 Google。

via: https://theartofmachinery.com/2020/08/04/leaving_google.html

作者：Simon Arneaud 选题：lujun9972 译者：JonnieWayy 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

代码英雄讲述了开发人员、程序员、黑客、极客和开源反叛者如何彻底改变技术前景的真实史诗。

什么是《代码英雄》

代码英雄 Command Line Heroes 是世界领先的企业开源软件解决方案供应商红帽（Red Hat）精心制作的原创音频播客，讲述开发人员、程序员、黑客、极客和开源反叛者如何彻底改变技术前景的真实史诗。该音频博客邀请到了谷歌、NASA 等重量级企业的众多技术大牛共同讲述开源、操作系统、容器、DevOps、混合云等发展过程中的动人故事。

本文是《代码英雄》系列播客第二季（3）：准备提交的音频脚本。

导语：想进入开源领域但不知道从哪里开始？你是一个贡献者，想知道为什么只有一些 拉取请求 Pull Request 被接受？或者，你是一个感觉有点不知所措的维护者？

这一集将探讨投身于一个开源项目的意义。我们将跟随我们的英雄们，跟着他们在开源贡献者的角色中不断进步：从寻找项目并为其做出贡献，到建立和维护繁荣的社区。Shannon Crabill 在 2017 年的 Hacktoberfest 上分享了她是如何开始从事开源工作的，而 Corinne Warnshuis 则介绍了将来自各种背景的人纳入到创造优秀软件的过程中是多么重要。

为开源做出贡献的方式有很多。让我们一起来了解一下。

00:00:03 - Nolan Lawson：

在我刚开始做软件开发的时候，我基本上只做些让自己开心的小项目，像小应用程序、命令行小工具之类的。

00:00:12 - Lindsey Tulloch：

我只是真的不知道作出贡献那么容易。而且你不需要解决 P = MP 那样的难题，你的投入依然可以是很有价值的。

00:00:21 - Kanika Muraka：

本地社区使我有了足够的信心去做出贡献。

00:00:28 - Saron Yitbarek：

当我还完全是个编程新手的时候，我和我的朋友 Dan 一起发起了我的第一个开源 拉取请求 Pull Request （PR），这也是我的第一次开源贡献。

00:00:42：

我听过很多为开源做贡献的故事，说它有多么神奇，有多么可怕。我很清楚，并非所有社区都和善，也不是所有维护者都很友好。

00:00:57：

那个项目本身对新手来说相当不错。我们只是添加了一个 JavaScript 库，让人们可以在线预览网站。这是一个很好的适用范围很广、自成体系的项目。而且如果这玩意儿不起作用，我基本上确信它不会毁掉整个网站。

00:01:18：

然而，我对这个 PR 非常紧张。我和 Dan 阅读了这个库的文档，埋头于写我们的代码。我仍记得当我们最终完成的时候，只是互相看着彼此，好像在说：“就这样吗？”我们发起了 PR。它被审查，然后合并，我想我至今还是对这一切感到惊讶，我还是不知道这些机制是怎么运行的。

00:01:43：

这并不是什么只有他们才能做到的，也不是什么神秘或神奇的事情。我意识到我确实也可以对开源作出贡献。这是我们在这一集中想要传递的一点知识 —— 为开源做出贡献并不神奇，它也不一定可怕。我们将带你一起走过这个过程。

00:02:05 - Lindsey Tulloch：

这是一个突破性的认识，这些项目实际上是完全开放的，我也可以做出贡献。

00:02:15 - Saron Yitbarek：

在这一场的开场白中，你会听到像你一样的代码英雄在加入开源行列时，经历着同样的恐惧。他们分别是 Nolan Lawson、 Lindsey Tulloch、 Kanika Muraka，这些是今天来做客的代码英雄。

00:02:34：

你正在收听的是红帽公司的原创播客节目《代码英雄》。我是主持人 Saron Yitbarek。

00:02:47：

这是一个关于两个代码英雄的故事，他们只是想在广阔的开源世界中，做出更好的东西。他们其中一个人是贡献者，另一个人是维护者。他们都不是真实存在的人物，而是两个虚构人物，用来代表所有的贡献者和维护者，他们和我们分享了他们的故事。希望你也可以在他们的历程中看到一些你自己的影子。

00:03:16：

首先来见一见我们的朋友 —— 贡献者。她是个新手，就像曾经的我们那样。她不确定基本的工作流是什么，但是她看到了一个需求，并且认为她可以添加一个功能来提供帮助。我们这个虚构的贡献者很想提交代码，但是该怎么做呢？

00:03:44 - Corinne Warnshuis：

你一直在成长，学习新技能。而且你不一定必须在孩提时代拆过电脑，才有资格在成年后学写代码。

00:03:52 - Saron Yitbarek：

这位是 Corinne Warnshuis，一个名叫“Girl Develop It” 的很棒的组织的执行董事。该组织的目的是帮助那些可能不太敢提问的，或在聚会中觉得自己不太受欢迎的女性。

00:04:07：

Girl Develop It 意识到做出贡献的难度并不是对所有人而言都是一样的 —— 这是社会造成的问题。作为社区，我们的一部分职责，就是要让世界多一点同情心，以及包容健康多元文化。

00:04:22 - Corinne Warnshuis：

在我们看来，加入开源的壁垒有很多，但我们喜欢称它们为“没有充分的理由”，有三个这样的壁垒将女性专门排斥在技术之外，它们是：刻板印象、可及性和环境。

00:04:40 - Saron Yitbarek：

值得记住的是，促进多元化不仅具有良好的道德意义，同时也有商业意义。

00:04:48 - Corinne Warnshuis：

作为一个行业，技术可能拥有着最大潜力，能给当今世界带来最大的变化。你确确实实希望，来自各行各业的人们都为塑造世界的工具、服务和其他事物做出贡献。我认为来自各种背景的人们一起开发软件，并为开源项目做出贡献真的非常重要。

00:05:13 - Saron Yitbarek：

事实是，我们并非一开始就拥有同样的优势和经验。下一代的伟大开发者可能看上去并不像硅谷的程序员。

00:05:23 - Corinne Warnshuis：

面对面指导对人们而言，历来是非常昂贵而又难以获取到的。再者，我认为从 2014 年至今，情况有所改善。我认为除了 Girl Develop It 之外的组织（比如 Outreachy 和 CodeNewbie ），正通过提供安全的网络或空间，来提出问题并获得更多的舒适感来做到这一点。

00:05:49：

为这些想法和问题提供一个安全而友好的测试平台，是一个不错的起点。

00:06:02 - Saron Yitbarek：

说到新手，回到我们正在追踪的那个贡献者。倘若你不是来自主流背景时，那么第一次提交可能会压力非常大。感觉就好像你必须得证明你自己。不过一旦我们将加入的壁垒降得足够低，我们在准备做出贡献时，实际需要考虑的是什么呢？

00:06:23 - Vincent Batts：

对某些项目感到兴奋这事很酷，但你想要解决的用例是什么呢？

00:06:31 - Saron Yitbarek：

Vincent Batts 在红帽主要从事容器架构方面的工作。他鼓励新的贡献者尝试并有针对性地开展工作。找到你和项目一起有意义的那个利基。

00:06:45 - Vincent Batts：

我认为一个可让人持续贡献的项目通常来自于互惠关系。它满足了你的一个需求，而且在这个过程中你又发现了满足它的需求的方式。即使它是一个由人构成的社区，它也已经成为了一种共生体系。

00:07:01 - Saron Yitbarek：

比方说：

00:07:02 - Vincent Batts：

因为朋友的推荐，我最终弄了一台 Slackware Linux 机器。它非常适合我想做的事情，我帮着将其打包到了主流 Slackware Linux 社区，并最终成为了这个项目的贡献者和维护者。这并不是因为我想成为 Slackware Linux 社区的贡献者，而是因为这是最适合我的一个项目，它的用例正好是我一直致力于解决的事情。

00:07:33：

我想很多人都会遇到这种情况，他们因自己量身定制的用例而编写一个数据库软件。他们发现用 Golang 编写很合适，因此他们写了这样一个高性能的数据库，所以他们能够对 Golang 做出修复或优化方面的贡献，以帮助他们的数据库运行得更快。

00:07:54 - Saron Yitbarek：

你可以找到你自己的小众领域，并开始自然发展。关键在于，从某处开始去做。你不必等待有了学位或绝对的自信才开始。

00:08:08 - Vincent Batts：

如果你需要直接编写代码或文档的经历，或是成为一个后端数据库、Web 服务器的系统管理员，那么好消息是，大部分社区都是基于志愿者构成的。你可以参与诸如 Debian、Fedora 或其他一些类似的项目，这些社区都建立起了文档页面。那些项目必须在某处的 Web 服务器上运行，一些人，甚至是一个没有薪酬的、正在积累经验的社区成员，负责去检查 Web 服务器是否停机或出了什么问题。

00:08:43 - Saron Yitbarek：

Vincent 强调了开源的平等主义本质。无论你来自哪里，只要你愿意，都可以真正开始做出贡献。如果你想的话，你可以为自己扬名立万。

00:08:57 - Vincent Batts：

一旦它被合并，你的名字就会附在某个项目上。你可以公开表示你在某个地方做出了改进，这是相当有意义的事情。

00:09:11：

我曾与那些不是从事日常技术工作的电视修理工和教师共事过，他们很有代表性。他们也在社区上做出了很多贡献。另一方面，我也曾和一些开发者合作过，他们有的能有 30 年开发经验，但他们从来没有像那样公开贡献过代码。

00:09:40 - Saron Yitbarek：

对了，我们的贡献者怎么样了？嗯，她找到了她的定位。她克服了她的恐惧，并最终发起了她的第一个 PR。现在她可以休息一下，并战战兢兢地等待维护者作出回复。

00:09:56 - Vincent Batts：

向上游做贡献有点像第一次上台做才艺表演。你会感到紧张，走上舞台后手心冒汗。你做了一件事，然后它好像就变成了你的成就。你将被彻底改变，跟过去不再一样。

00:10:17 - Saron Yitbarek：

彻底改变？或许吧。事实上，维护者有四种可能的回应：沉默 —— 这很有趣，也可能是完全拒绝，或是直接接受，或是柔和的中间立场 —— 要求修改。

00:10:37：

提交 PR 的几天后，我们虚构的贡献者终于收到了来自维护者的回复。跪迎结果吧，是要求修改。作为一个新手，她将这视为一场小型灾难。她还不知道要求修改是个实际上是成功的一步。她甚至还对维护者的简略语气感到一点气愤，听上去就像维护者没空搭理她一样。

00:11:03：

这里存在着一堵墙，新的贡献者不知道墙的另一边正在发生什么。

00:11:12：

我们来认识一位维护者。他正在维护的项目并不是他的全职工作。这是一个周末项目，他时常熬到深夜，给工单排优先级，并且提醒人们发起 PR 时更新文档，然后你就明白了。他相当忙碌，有时甚至出现了一些维护倦怠。

00:11:38：

一位现实生活中的维护者，Nolan Lawson 写了一篇很棒的有关倦怠的文章，最近引起了很多关注。

00:11:51 - Nolan Lawson：

老实说，我认为那篇博文有一部分实在寻求帮助。这是我表达我自己偶然发现了这个开源的项目，起初我觉得它确实很有趣，但现在却感觉没那么有趣了。我不确定该如何恢复兴致。

00:12:05 - Saron Yitbarek：

Nolan 有一份日常工作，但和大多数维护者一样，他在开源项目中投入了大量的休息时间，因为这家伙真的很在意这个项目。讽刺的是，他的部分痛苦来自于，他清楚贡献者也同样很在意这个项目。

00:12:23 - Nolan Lawson：

真正使我精疲力竭的实际上只是如潮水般涌来的好心人。你真的想帮他们，真的真的很想。他们所做的只是问一个问题，他们所做的就是 —— 他们在你项目中发现了阻碍他们的 bug，或者他们所做的只是 —— 他们真的费心去下载代码并弄清楚它是如何构建的，并提供 bug 修复。他们只是希望你审查他们贡献的代码。

00:12:43 - Saron Yitbarek：

像 Nolan 这样的维护者正不断地审查 PR 库，弄清每个提交将如何发挥作用。他们促使贡献者尽可能做到最好，遵守内部限制，为了能让项目达到更高的水准，用最有意义的方式做出贡献。

00:13:06：

我的观点是，那些维护者有可能不是一个新贡献者所担心的混蛋。他们正努力地想去做到一切。他们甚至会花时间标注一些东西保留给新手（很多维护者都这样），以便新手有机会施展自己。

00:13:27：

但到最后，PR 和提交总是非常的多。我们要如何确保这种情况不会发生呢？我们该如何为维护者创造合理的环境呢？

00:13:41：

一种解决方案是 —— 像 Fedora 这样拥有强大社区的开源项目。Fedora 项目负责人 Mattew Miller 解释了项目吸引维护者和贡献者的地方。

00:13:55 - Matthew Miller：

Fedora 项目中许多不光是开发，还有开发过程中所相关的一切。总体来说，IT、 CS（计算机科学）事实上都是如此。开源可能并没有足够的这类围绕开源的支持性的角色。

00:14:11 - Saron Yitbarek：

那种支持实际上看起来是怎样的呢？

00:14:14 - Matthew Miller：

我们拿来举例的带薪角色之一是 Fedora 项目经理，他帮着让计划按部就班进行，并且监管着人们来保证文书工作完成。让人有酬劳地来做这份工作事实上可以帮着减少官僚主义，因为他们可以把时间花在使项目成为人看懂的事情，而不只是一堆杂乱的文件。

00:14:34 - Matthew Miller：

我认为，像这样的企业参与某些角色，可以赋予你无法用志愿者保证的稳定性。

00:14:43 - Saron Yitbarek：

这有点让我想起了自由职业者使用的共享工作空间。那里有一个共享的接待区、共享的 WiFi 和共享的咖啡。有一个人在管理它，然后你就可以自由地做你自己的事情。

00:14:55：

Matthew 告诉了我们另一个 Fedora 采取的策略。他们让你想在项目中途停下来休息一下时，可以很自然，而不是感觉一切都崩溃了。

00:15:04 - Matthew Miller：

我们研究的一个问题是确保领袖角色的漂亮退场，所谓的职位并不一定是终身的委任。你可以重新申请担任角色，并且不会在一年任期后结束后，看起来像被踢出去似的。如果六个月后你想离开，你可以优雅地这样做，而不必觉得这会让人失望。我们已在努力确保人们可以没有障碍地退出。

00:15:27 - Saron Yitbarek：

Matthew 认为，找到支持该开源社区的方法，而又不至于重蹈覆辙才是关键。

00:15:35 - Matthew Miller：

社区几乎就像一个家庭，而不是工作场所之类的东西。在这里做出贡献很有意义，因为你不仅只在为自己或是某些薪酬或终端产品工作。而且由于共事的是你的朋友，你们一起工作能做出比单人作品更伟大的东西。

00:15:56 - Saron Yitbarek：

无论是 Fedora 还是其他社区，它们都造就了一个开源贡献得以持续的世界，这个世界还值得努力让它继续变好。

00:16:10：

同时，让我们回到办公桌旁，我们关注的那个贡献者刚完成了维护者要求的修改。她还没意识到，但她即将拥有第一个被接受的 PR。

00:16:24：

当我们谈论诸如倦怠之类的长期工作的问题时，很容易忽视那些早期问题。每天都有很多新的贡献者加入进来。这实际上就是为什么我们需要构建可持续的社区，为所有这些开源魔术提供场地。

00:16:49：

最终，我们的贡献者和维护者共同努力，推动事情向前发展。故事的最后一句话 —— 记住所有的交流都依赖于 GitHub 和 GitLab 之类的开发平台，这些平台使得我们可以聚集到一起。

00:17:09：

我想深入探讨一下这些社区是如何使我们的工作成为可能的。我和 Shannon Crabill 谈过这个问题。Shannon 白天是个电子邮件开发者，但到了晚上，她正在学习前端开发。她也是一个对社区价值有第一手了解的人。

00:17:28：

去年她参加了一个长达一个月的名为 Hacktoberfest 的开源活动，该活动旨在让更多的人为开源做出贡献。当时， Shannon 完全是一个开源新手。

00:17:44 - Shannon Crabill：

回想起十月那时候，我感觉我没有太多工作要做，而且可能还有更多的新手，没找到需要做的东西。如果我提出一些相对容易的待办事项，他们就可以找到用于尝试和学习的突破口，并且开始习惯使用 Git 和 GitHub。

00:18:04：

我认为最困难的部分，在于习惯工作流程并付诸实践。如何推送存储库？如何分享项目？如何处理 PR 和相关的东西？我帮助人们对开源做出了贡献，这事令人惊讶，感觉也确实很棒。

00:18:21 - Saron Yitbarek：

真的很恐怖吗？我觉得如果你是个新手 —— 尽管你拥有存储库，也要走出自己的小世界，把自己放在社区里。现在，维护者所在的社区里出现了正在作出贡献的人，你必须和他们交谈，审查他们的代码并发表意见。这听上去是有点吓人。

00:18:42 - Shannon Crabill：

我认为最初的反应是，“哦，我的天哪，这太酷了”，还有，“天哪，我让自己陷入了什么境地？”我意识到我只合并过自己的代码，合并过自己的 PR 并将其推送到自己的站点上，以及其他所有只关于自己的事情，我从没处理过别人的东西。我认为我之前尚未完成过真正意味上的合并 PR，所以我不得不把这弄清楚。总的来说，将复杂的东西简单地合并起来，仍然是我要努力熟练解决的问题。

00:19:09：

这是旋风一样的感觉，“这很酷，但我不知道该怎么做。”每个人都很友好，并且我也努力保持非常友好和真诚，即使只是，“嘿，我有点不知所措。我看到了每个人提交的 PR。虽然今晚我不会找他们，但我明天会的。”人们对这种情况似乎反应良好。

00:19:26 - Saron Yitbarek：

是的。当你维护一个项目时（尤其是作为一个新的开发者时），我一直想知道的是，是不是这意味着你必须是整个存储库贡献者中最聪明的人？你实际上在评估、评判并审查其他人的代码。你是否遇到过，自己懂的东西不如提交 PR 的人那么多的情况？你是如何处理的？

00:19:55 - Shannon Crabill：

好问题。我认为，“噢，我需要成为有史以来最聪明最好的开发者”，这样的想法会成为障碍。我觉得自己很幸运，当我进入这个领域的时候，我没有这样想，所以我能像这样说，“让我们先开始，并且期待未来会发生什么吧。”

00:20:12：

你无需成为一个有 20 年经验的高级开发人员。你只需要有一个好点子，知道如何使用相应软件，然后愿意去学习自己不知道的东西。

00:20:22：

肯定有一两个 PR 为我的项目添加了一些很酷的功能，说实话，如果它们崩溃了，我真不知道该如何修复。我可能会看着代码然后想道，“是的，它崩溃了。”我不知道该怎么做才能从头构建它们。

00:20:34：

我认为这就是它酷的地方。如果只有我一个人在做贡献，我可能就做了一些基本的工作，但没法像其他拥有丰富经验的人所作出的贡献一样，将项目变得那么酷。

00:20:45 - Saron Yitbarek：

作为一个维护者，在使项目更易于访问，更加友好，更加易于贡献的过程中，你学到了些什么呢？

00:20:55 - Shannon Crabill：

哦，确实有件我认为很有帮助，并且我希望我一开始就做的事，那就是尽可能的建立模板，以及文档、文档、文档。

00:21:07：

我的确在我的 README 文件里加了很多东西，并且我认为在项目开始时有一个 README 文件确实是很重要的一步。这件事情意味着你对其他人大声说，“嘿，请查看我们的贡献指南。”我认为我制作了一个 PR 模板、一个议题模板，“单击这里查看当前议题”，这样人们才不会多次提交同样的内容。

00:21:31：

我认为让项目尽可能简单，或尽可能对用户友好，这是你作为维护者需要迈出的一大步。

00:21:38 - Saron Yitbarek：

绝对是这样，我经常看到 README 文件，经常听说他们有多么多么重要。我觉得在 README 文件里还可以做很多事情。归根结底，它就像是一个空白文档，告诉别人去阅读它。你应该在文档里写什么呢？你该如何构建它，来使得它真正与希望做出贡献的人产生关联呢？

00:22:00 - Shannon Crabill：

我在我的 README 文件里放了很多 gif。

00:22:03 - Saron Yitbarek：

很好。

00:22:05 - Shannon Crabill：

我有 gif，也有链接。

00:22:07 - Saron Yitbarek：

我一开始就知道 Shannon 已经认识到了合作关系的重要性。她早就知道，如果有人被邀请来协作，这项目就会变得耀眼，大家也会因此度过美好的时光。

00:22:20 - Shannon Crabill：

有人用开源项目作出很棒的事情，我也认为这很有趣，而且有个有意思的项目，“嘿，我制作了这些很酷的蝙蝠，每次你单击页面的时候，它们都会随机生成。”

00:22:33 - Saron Yitbarek：

我也喜欢人们做不同的事情。如果你真的很喜欢艺术性的东西，你可以做蝙蝠生成功能。如果你想让项目变得整洁，你也可以做。如果你想说，“我会坚持贡献文档，我将花时间为其他的贡献者们打造更干净，更舒适的环境”，那你也可以选择做这个。

00:22:56 - Shannon Crabill：

是的。我已经说得很清楚了，无论你想贡献的是什么，都没有问题。如果你发现了一个拼写错误并且想要纠正它，很好。如果你发现某个链接损坏并且想要修复它，也很好。如果你只是想帮着注释这份代码，使得它更易于阅读和理解，那也将很有帮助。

00:23:12 - Saron Yitbarek：

我认为，你在社区中获得了积极的反馈真的很棒，因为我听说过很多并不是这样美好的故事。人们在网络上并不十分友好，也不太热情善良，尤其是对我们这一些，可能会问出比他们想象中更简单问题的新手。

00:23:33：

你认为，是什么使得你的社区，比起其他社区更加友好呢？

00:23:41 - Shannon Crabill：

只是因为在我们社区，贡献是一件很随意的事。如果你想做出贡献，你可以，这很酷。如果你不想，那也很酷。我理解有人认为开源是一件令人恐惧的大事，你需要具备所有这些经验，并且了解所有这些复杂的语言，或是前后端以及其他的一切，才能够做出贡献。

00:24:03 - Saron Yitbarek：

绝对是这样。做 Hacktoberfest，它是怎样改变了你现在对开源的想法？

00:24:11 - Shannon Crabill：

它肯定对我造成了积极的影响。就像我说的，我有过很棒的经历，而且我希望每一个以某种方式参与我项目的人也能有很好的经历。这毫无疑问促使我想去尝试更多类似的事情，即使它们没有进一步的发展。现在这看起来这些项目更加平易近人了。

00:24:32 - Saron Yitbarek：

真是个好消息。

00:24:34：

这儿有个信息，来自数百家公司的数千人，以及一些根本没在公司工作的人，为 Linux 内核做出过贡献。这意味着基本上运行着互联网的 Linux 是由一群日常英雄在维护的。如果你渴望为开源作出第一次贡献，或许你会想了解有关 Fedora 社区的更多信息，我们有大量的资料正等着来帮助你。请查阅 redhat.com/commandlineheroes 以获得更多信息。

00:25:20 - Saron Yitbarek：

快速提醒一下，这一季我们将构建我们自己的开源《代码英雄》游戏。欢迎你以对你来说合适的方式来做出贡献。快来了解如何成为其中一员吧。我们希望你可以通过 redhat.com/commandlineheroes 和我们一起开发这款游戏。

00:25:42 - Saron Yitbarek：

下一集，我们将讨论残酷的达尔文式错误以及开源开发中失败的美丽之处 —— 它如何困扰我们，指导我们，并使我们变得更好。

00:25:57 - Saron Yitbarek：

《代码英雄》是红帽的原创播客。你可以在 Apple Podcast、 Google Podcast 或是其他你喜欢的途径免费收听。我是 Saron Yitbarek，坚持编程，下期再见。

什么是 LCTT SIG 和 LCTT LCRH SIG

LCTT SIG 是 LCTT 特别兴趣小组 Special Interest Group ，LCTT SIG 是针对特定领域、特定内容的翻译小组，翻译组成员将遵循 LCTT 流程和规范，参与翻译，并获得相应的奖励。LCRH SIG 是 LCTT 联合红帽（Red Hat）发起的 SIG，当前专注任务是《代码英雄》系列播客的脚本汉化，已有数十位贡献者加入。敬请每周三、周五期待经过我们精心翻译、校对和发布的译文。

欢迎加入 LCRH SIG 一同参与贡献，并领取红帽（Red Hat）和我们联合颁发的专属贡献者证书。

via: https://www.redhat.com/en/command-line-heroes/season-2/ready-to-commit

作者：Red Hat 选题：bestony 译者：JonnieWayy 校对：acyanbird, wxy

本文由 LCRH 原创编译，Linux中国 荣誉推出

这是一篇 LCTT 七周年的纪念文章，也是 LCTT 承前启后的一个里程碑。

写在 LCTT 七年之际

在 7 年前的今天，我并没有想到，在一个偶然的机会下诞生的 LCTT，它能走过这么长的时间，留下这么多的印痕。是的，一些老朋友或许记得，LCTT 这个 Linux 中国旗下的最主要的开源活动/组成部分，最初只是我发心想完善 man 的中文翻译而产生的副产品。结果，man 中文翻译项目没有做成，而 LCTT 却持续地运营了下来。

虽然，这些年 LCTT 屡有改进和完善，但是总体来说还是相对保守。当然，LCTT 这些年已经陆续有 400 多位贡献者实质性的参与了贡献，并在此基础上创建了几个 SIG（特别兴趣小组），如红帽代码英雄 SIG、漫画 SIG、LFS SIG 等。

作为回顾，我来介绍一下 LCTT 这 7 年间在主项目（TranslateProject）上取得的成就：

• 贡献者： 435 位
• 翻译文章：5687 篇
• GitHub 提交：54629 次
• GitHub 拉取请求：19243 次

这是 LCTT 主项目的提交图：

这其中，钻石级的贡献者有 5 名，五星级贡献者有 6 名，13 位 4 星贡献者。那么，请让我来用一段视频展示一下 LCTT 七年来的历程：

当然，整体的贡献水平呈现长尾分布，大部分贡献者浅尝辄止，我想除了贡献者存在着体验的心态之外，也与 LCTT 没有建立起来合适的社区引导和激励机制有关。此外，就开源社区/开源项目而言，我们也存在一些不足，比如，按 GitHub 建议，我们在如下社区建设方面还缺乏：

• 社区行为准则
• 贡献指南
• 议题模板
• 拉取请求模板

因此，在写这篇文章时，我也要宣布一件事，就是我会逐渐淡出 LCTT 的日常管理，改组 LCTT 管理团队，将更多未来的可能交给社区成员来建设，也希望新的社区管理团队可以为 LCTT 创造出一个不同的明天。

以下，请我们的 Linux 中国的核心合伙人 Bestony 来介绍一下今后 LCTT 的发展计划。

大家好，我是 Bestony，感谢老王数年来的坚持不懈的投入，正是有老王的坚守，才能有我们如今的成就。在接下来的时间里，我将会帮助老王，更好的运作 LCTT，让老王可以喘口气，也为 LCTT 带来一些新的气象。

在过去的七年里，我们 LCTT 做了很多事情，我们翻译了数千篇文章，有数百位技能精湛的贡献者。如今，到了 7 年的这个节点上，我也在思考，我们下一步应该怎么走。

其实，在过去的一年里，LCTT 的问题在不断的浮现：选题方向单一、译者进入门槛较高、大家翻译的质量水平参差不齐、校对的人手不足、译稿外发的反馈不足，这些问题都是我们在过去遇见，但一直没有足够的精力和人力来解决的问题。不过，如今我将加入到 LCTT 的管理团队中，配合老王，一起一个个的解决这些过去遇见的问题。

对于这些问题，有一些我们已经在解决，比如“选题方向单一”，在今年的年初，LCTT 与红帽公司（RedHat）联合建立了 LCRH SIG，面向红帽旗下的原创播客《 代码英雄 Command Line Heroes 》进行定向的翻译，目前，第一季度的翻译成功已经全部在 Linux 中国公众号上发布，而第二、三季度的内容，也正在不断的发布过程中。

LCTT - SIG 将是后续的新的发展方向。我们将会在保留 LCTT 主体的基础上，鼓励各位译者探索更多的兴趣方向，通过建立起不同的 SIG，引入更多的翻译内容，来帮助大家更好的达成自己想要的翻译目标。并且，通过 LCTT 的技术和经验，赋能每一位译者，帮助译者更好的学习、了解各种不同领域的知识。

而在“进入门槛较高”方面，一直以来 Github 的访问慢问题、Git 的概念不熟悉等问题，都是困扰不少新同学的点。而也正是这些点，在不断制约着 LCTT 的发展。在将来，我希望 LCTT 可以打造出自己的翻译工具（也将会为之而奋斗），通过工具辅助的方式，帮助更多人走上翻译的道路，让更多的爱好者们，可以为中文的技术环境贡献一份力。

后续，我们将会引入翻译工具、自建关键词表、多轮校对手段等方案，帮助更多的译者完成自己的翻译文章，通过翻译，学到自己想要的知识。

当然，问题并不止我点出来的这些，我们能发展到今天，一定有很多做对了的地方，但同样，我们也有做错了的地方。欢迎你随时联系我，讨论你对于 LCTT 下一步的想法，我相信，你的意见能够帮助 LCTT 变得更好。

最后，千里之行，始于足下，刚刚走过 7 年的 LCTT， 希望我们可以在下一个七年，再次相遇。欢迎加入 LCTT：https://linux.cn/lctt/

代码英雄讲述了开发人员、程序员、黑客、极客和开源反叛者如何彻底改变技术前景的真实史诗。

什么是《代码英雄》

代码英雄 Command Line Heroes 是世界领先的企业开源软件解决方案供应商红帽（Red Hat）精心制作的原创音频播客，讲述开发人员、程序员、黑客、极客和开源反叛者如何彻底改变技术前景的真实史诗。该音频博客邀请到了谷歌、NASA 等重量级企业的众多技术大牛共同讲述开源、操作系统、容器、DevOps、混合云等发展过程中的动人故事。

本文是《代码英雄》系列播客第二季（2）：Hello, World的音频脚本。

导语：每一种新的编程语言的诞生，都是为了做一些以前无法完成的事情。如今，有非常多编程语言可以选择，但哪些才是你真正需要了解的？

本集将深入探讨编程语言的历史。我们将会了解到被称为 “神奇葛丽丝” 的天才 —— 海军少将葛丽丝·哈伯。多亏了她，开发者不再需要数学博士的学历就能使用机器代码编写程序。参与录制的还有 Jupyter 项目的 Carol Willing，她是 Python 基金会的前理事；以及《 纽约时报杂志 New York Times Magazine 》和《 连线 Wired 》的撰稿人 Clive Thompson，他最近正在撰写一本关于程序员如何思考的书。

00:00:07 - 各种语言：

“你好，世界。”

00:00:12 - Saron Yitbarek**：

你好，世界。现在我们发出的是信号还是噪音？我们日日夜夜无休止地写代码，做测试工作，我们追求的事情只有一个：我们是否传递了我们的信号？

00:00:29 - 各种语言：

你好。

00:00:29 - Saron Yitbarek：

或者我们的信号是不是丢失了？难道我们一直在制造无意义的杂音吗？

00:00:40：

我是 Saron Yitbarek，这是代码英雄第二季，来自红帽原创播客。今天的话题将在“翻译”中挖掘。这关于编程语言的故事：它们是怎么来的，如何选择其中一个语言来学习。我们将深入研究如何与机器对话。探究这些语言是如何演化的，以及我们如何用它们来让我们的工作变得更好。

00:01:08 - Sari：

Daisy，daisy，来告诉我你的正确回答。

00:01:11 - Saron Yitbarek：

如果你像我一样是一个开发者，你可能也经受着去精通多种语言的压力。最起码你得会 Java，更好一些得懂 Python、Go、JavaScript、Node，甚至能够用 C++ 思考。也许为了增加可信度，可能你还要熟悉古典的 COBOL。甚至你还得学点新东西，比如 Dart。实在太累了。

00:01:36：

奇怪的是，我们正在讨论的计算机只讲一种语言：机器语言，以二进制形式飘过的 1 和 0。说到底，我们学习的每个语言都是殊途同归。不管有多抽象，它都是用来简化我们工作的道具。

00:02:03：

这就是我希望你们记住的，故事开始了，从那一刻，那一个经典辉煌的时刻，一个女人说：“你知道么？我是人类，我不想用二进制来讨论思考，我就想用英语去编程。”

00:02:22：

在今天可能看来是一个简单的概念。但曾几何时，使用人类的方式与计算机对话这个主意 —— 说轻点是一个笑话，严重点就是亵渎。

00:02:37：

代码英雄第二季，将讲述成就我们基础的螺丝钉展开。这一讲的英雄是一个女主人公，如果你想要进一步了解故事，你必须知道她的经历。在此给你们隆重介绍：软件界的第一夫人。

00:02:58 - 发言人：

尊敬的先生们和女士们，我非常荣幸的给你们介绍 葛丽丝·玛丽·哈伯 Grace Mary Hopper 准将，谢谢。

00:03:02 - 葛丽丝·哈伯：

我曾到加拿大的圭尔夫大学演讲，那时候我必须在多伦多的机场办理入境手续。我把护照递给移民官，他打量了护照和我说：“你是在哪里工作的？”

00:03:17：

然后我说，“美国海军。”

00:03:20：

她再次深深的打量我一下。然后他说：“你一定是海军里最老的。”

00:03:28 - Saron Yitbarek：

她就是 1985 年担任海军少将的葛丽丝·哈伯。在麻省理工学院发表了著名的演讲时，她 79 岁。即使在那时，她也是一个传奇人物。她是独立编程语言之母，实现通过编译器，用人类语言替代数学符号编程这一伟大成就的女性。

00:03:51：

她获得了国家技术奖章，她去世后（1992 年），被追授国家自由勋章。以上记录纯属真实，他们称她w为“神奇葛丽丝”。

00:04:03 - Claire Evans：

如果有人能够被称为天生的程序员，那么这个人一定是葛丽丝。

00:04:06 - Saron Yitbarek：

这是 Claire Evans，一个科技记者和《 宽带 Broad Band 》一书的作者，而这本书讲述了科技领域的女性先锋。Evans 描绘了早期的计算机世界，在 1940 年，当葛丽丝·哈伯还是一个年轻的女孩时，她加入了美军的海军预备役部队。当时的电脑有一个小房子那么大。

00:04:25 - Claire Evans：

早期的那些程序员，他们就像一个圣职者。他们是一群擅长做枯燥乏味事情的人，因为那会儿没有编译器，没有编程语言，人们是确实是一个比特一个比特地对机器编程。

00:04:42：

想要改变这种现实，你真的必须是一个特别的人，而葛丽丝真的就是那种人。

00:04:49 - Saron Yitbarek：

现在，她意识到让人类使用机器语言的是一种多么疯狂的限制。就像走路的时候，去告诉你身体的每个原子该怎么做。这是可能的吗？是，效率呢？不高。

00:05:06：

在程序员的意图和计算机的行为之间一定有一条捷径。自从有了算盘，人类一直在将数学思维机械化。一定有一种方法可以在计算机上再次实现这一点。

00:05:19 - Claire Evans：

在过去，数学家必须做出所有的步骤。所有这些枯燥的，一步一步的工作都是为了得到一个真实而有趣的答案。然后有了计算机后，它尽可能地承担了这些机械的运算。所以解放了数学家去进行高层面的、更智慧的、面向系统的思考。

00:05:39：

只不过，事实并没有如此发展。有了计算机，数学家就变成了程序员。他们又一次被这些枯燥无味的编程所束缚，做着这些一点一滴的繁琐的规则导向的小计算。

00:05:53：

因此，我认为，葛丽丝的期望是，她希望计算机能够辅助数学家，然后数学家就可以去更进行宏大的思考，做更伟大的事情，而不至于让他们陷入细节之中。

00:06:12 - Saron Yitbarek：

葛丽丝也加入了思想家的行列。我们都知道， 帕斯卡 Pascal 在 17 世纪发明了第一台计算器。 巴比奇 Babbage 在 19 世纪发明了分析机。这些伟大的杰作是发明家们解放人类的大脑的创作。这些发明让我们处理数据的能力空前绝后。这就是葛丽丝踏入的领域，发明了所有人都认为不可能的东西。

00:06:42 - Claire Evans：

我觉得，葛丽丝的想法是，人们应该用人类语言与计算机沟通。这个语言必须独立于机器的，因此不同计算机可以交互操作，这在当时是革命性的。

00:06:59：

早期她称这个为 “自动化编程”，在程序员和计算机人的群体中，被认为是像太空学员一样。

00:07:12：

而那些迟迟不上岸的人们被看成了尼安德特人，这在当时是计算机界的一个巨大的分歧。

00:07:21 - Saron Yitbarek：

葛丽丝要说服她的上级跨越这个分歧并不容易。但她认为这是她的责任，她必须尝试。

00:07:30 - 葛丽丝·哈伯：

这里总是有一条线，那条线代表了你的老板在那个时候会相信什么。当然，如果你过线了是得不到预算的。所以你对那条线有双重责任：不要踩过它，但也要不断教育你的老板，让你把这条线移得更远，这样下次你就能走得更远。

00:07:52 - Saron Yitbarek：

她推动的那个未来，就是我们的现在。几乎你我依赖的每一种语言都归功于她和她的第一个编译器。因此太空学员们活了下来，尼安德特人灭亡了。

00:08:07：

写代码不用数字，而是用人类风格的语言是她的观点。你敲下“执行操作 8”，或“关闭 文件 C”的精简操作，才是符合人类习惯的编程。

00:08:21 - Claire Evans：

葛丽丝独特地意识到，计算将成为改变世界的事情。但是如果没有人知道如何接触并使用计算机，那么它就不会成为改变世界的事情。因此她想确保它对尽可能多的人开放，尽可能多的人可以使用。

00:08:37 - Claire Evans：

这就需要编程在可理解性和可读性上做一些妥协。因此最终创造一个编程语言的目标就是给机器提供更多切入点，让它脱离这个神职，让它的开发面向大众和未来新一代。

00:08:59 - Saron Yitbarek：

我想在这里打断并强调下 Claire 的说法：现在我们所已知的编程语言，都来源于科技开放的愿望。这让计算机不再是数学博士们的专属玩具，让编程开发变得更容易。

00:09:14：

编译器所有工作的本质，是让程序变得更好理解，更有人性。

00:09:21：

Claire 有一个猜测，为什么葛丽丝是做出改变的那个人，这与她在二战期间的工作有关。

00:09:29 - Claire Evans：

她的工作是解决扫雷问题、弹道问题和海洋学问题。她用很多不同的、交叉的学科来模拟战争里的所有的暴力、混乱和现实的灾难，并将他们转化成在 Mark I 计算机上运行的程序。

00:09:45：

她知道如何在语言之间去做翻译转换。我的意思不是说计算机语言，是人类语言。她知道如何倾听一个提出复杂问题的人的意见，并尝试理解问题的背景，其信息和所涉及的专业规律，然后将这些转为计算机可以理解的程序。

00:10:06：

从这个角度看她如同早期的编译器。就像一个人类版本的编译器，因为她知道你必须理解他们才能满足他们的需求。

00:10:17 - Saron Yitbarek：

编译器干的事情就是一个解释和理解。我觉得我们应该在学习新语言，或想知道为什么有一些东西根本不能编译的时候牢记这个理念。编译器的工作就是满足你使用生活中说的语言来编程。

00:10:32：

葛丽丝知道人类一旦可以学会讲编程语言，而编译器可以将我们的意图转换为机器语言，就像为洪水打开了大门一样。

00:10:43 - Claire Evans：

她知道如果计算机太孤立和太具体，就不会发展为一个产业，从而成为改变世界的力量。也就是说计算机的从业者，可以让提出问题的人跟机器直接沟通。

00:11:00：

因此她真的是一个善于人类语言翻译的专家，至少我是这么想的。这使她有独一无二的机会，去思考和创建编程语言。

00:11:15 - Saron Yitbarek：

葛丽丝对英文式数据处理语言的研究最终演变成了 COBOL，它在某种意味上很不错。因为它不浮华，很适合商务用途，葛丽丝·哈伯也是这样的人。

00:11:28：

从某种角度看，她给了我们一个很像她的语言。像葛丽丝一样，COBOL 语言也很长寿，它现在已经 60 多了。

00:11:50：

葛丽丝的编译器就像一个 巴别鱼 babelfish ，在程序员和机器之间充当翻译，不过它们翻译的都是高度概括性的语言。

00:12:03：

然后，几十年之后，另一个重要的思潮在语言界兴起。想象下画面：自由软件社区在 1980 年出现，但是 Unix 的替代品 GNU 被开发出来后，却没有任何自由开放的编译器随之出现。

00:12:22：

为了让 GNU 给我们提供一个真正的开源 UNIX 替代品，为了让编程语言在开源世界蓬勃发展，社区需要找来一个格蕾丝·哈伯 —— 我们需要一个开源编译器。

00:12:38：

这是 Langdon White，红帽的平台架构师，来讲讲他对这个事情的理解。

00:12:45 - Langdon White：

在 80 年代，你要买一个编译器很轻松就要花上上万块钱。费用是最大的问题，我没有多余的钱去给自己买编译器。再一个事实是，我必须为所有我想要的目标平台买一个对应的编译器。那个时代大部分是 Unix 平台，但是细节和风格各不相同。

00:13:06：

因此你就不能买一个，你需要为不同的架构，不同的供应商购买多个编译器。

00:13:14 - Saron Yitbarek：

Langdon 指出这不仅仅是成本问题，在一些情况下，对编码工作也带来了问题。

00:13:21 - Langdon White：

大家都没有意识到，你如何用很特殊的方式来组织你的代码是很重要的。做嵌套 for 循环或者做嵌套 while 循环之类的事情可能是可以的，这取决于编译器。

00:13:38：

因此，大家都应该明白，如果你不知道编译是如何优化你的代码的，就很难知道如何写出最优的代码。

00:13:49 - Saron Yitbarek：

必须要提的是，我们需要一个免费的、可获得的、可值得信赖的编译器。这就是 GNU C 语言编译器：GCC。它横空出世在 1987 年，它是格蕾丝·哈伯的编译器革命和自由软件运动的结合。

00:14:12：

它是使编译更标准化，从而让所有人可以编译别人写的代码。我们编程语言的丰富性要归功于它。

00:14:22 - Carol Willing：

GCC 是开放的，可以说将编程语言推向一个更高的层次。

00:14:29 - Saron Yitbarek：

这是 Jupiter 项目成员 Carol Willing，她是 Python 软件基金会的前理事。

00:14:35 - Carol Willing：

人们开始意识到，专有的语言会在特定时间内被服务于一个目的，但并不能得到开发者社区的认可和热爱。因为如果你是一个开发者，你希望学习最常用的，以及未来最流行的东西。

00:14:59：

我没必要去发展一种将我锁定在一种技术上的技能。我想 Python 成功的一个原因是因为它是开源的，它有非常简洁的语法。

00:15:11：

它的特点就是允许人们用常见的方法，快速高效地解决问题，也允许大家合作解决问题。我想这就是好的程序和代码库的标志：如果你可以用最小的工作量完成你的工作，并且与他人分享，这是确实很棒的事情。

00:15:35 - Saron Yitbarek：

这么多年过去了，GCC 逐渐的支持了 Java、C++、Ada 和 Fortran 语言，我还可以继续说说它的进步。

00:15:43 - Carol Willing：

通过像 GCC 这样的通用底层接口，人们可以根据自己的特殊需求来定制语言。例如，在 Python 的世界里，有大量的库，甚至具体到科学 Python 世界里，我们有 numpy，还有 scikit-image、scikit-learn 这样的东西。

00:16:08：

每个库都是为一个特定目的而工作。因此，我们也看到了生物信息学和自然语言处理之类的东西。而人们可以在一个共同的基础上，做出很多不同的事情。而且可以把它们放到编程语言或库里，使他们能够在他们特定的行业或领域中优化问题的解决。

00:16:42 - Saron Yitbarek：

因此，这就是编译器技术一头撞进开源运动的结果吧？随着时间的推移，这种不同技术的碰撞，爆炸般地创造了一个新的、被社区支持的语言，大家都可以学习和完善它。

00:16:58：

现在有成百上千的编程语言存活着。

00:17:03 - Carol Willing：

随着开源软件越来越流行和被广泛接受，我们看到了编程语言的大量激增。现在有大量围绕着手机技术的编程语言，不同的编程语言也让游戏开发更加简单快速便捷。各种用途的语言，如 Python 和 Ruby，它们算是现代网页开发和交付网页应用和网站的基础。

00:17:34 - Saron Yitbarek：

这个队伍还会继续壮大。是的，我们建造的这个巴别塔在未来会更加拥挤。但是你可以把它当作一个聚宝盆，一个语言的盛宴。下面我们将会帮你们梳理这个盛宴。

00:17:55：

现在我们已经知道编程语言泛滥的原因了。但是这些对我们有什么具体的意义？我们如何选择对我们重要的语言呢？这是个大问题，因此我们找了一些人帮忙：Clive Thompson，是最好的作家之一，他能让科技世界变得更有意义。他是《连线》的专栏记者，《纽约时报》杂志的特约撰稿人，他现在正在写一本关于计算机程序员心理学的书。

00:18:24：

当我们挑选我们想要学习的编程语言时，我们需要知道我们到底想要什么。

00:18:31：

这是我和 Clive 反复讨论得出的结论。

00:18:35：

当我作为一个开发新人第一次入手的时候，我就说：“让我选一个最好的编程语言，然后掌握并熟练运用它，不就完事了么。”

00:18:44：

不过事情不会这样简单，否则为什么有那么多的编程语言呢？

00:18:49 - Clive Thompson：

每个语言都有那么点它的特长。因此通常来说，有人创造一个新语言是因为现有的语言满足不了他们的需求。JavaScript 就是一个典型的例子。

00:19:03：

网景公司 Netscape 曾经在 90 年代中开发了一款浏览器，所有的网站管理员想做一些更具交互性的事情。他们希望有一种方法，使其可以在网站上运行一些脚本。

00:19:16：

当然这些需求都提给了网景。然后他们说：“好吧，现在我们没有可以做到这一点的办法，我们需要一个可以集成到我们浏览器的脚本语言。”

00:19:25：

于是他们雇佣了 Brendan Eich，一个被认为很资深的家伙。他当时 32 岁，其他人 21 岁的样子。

00:19:32 - Saron Yitbarek：

这在开发者圈里就很资深了

00:19:35 - Clive Thompson：

他们给他 10 天时间开发 JavaScript。因此他真的就 10 天没有睡觉，然后疯狂地捣鼓出一个脚本语言。它看起来有点挫，有点糟，但是可以运行。它允许人们做一些简单的事情，它还有按钮，对话框，弹框和其他东西。

00:19:54：

这就是造一个编程语言的例子，用来做在当时没有办法完成的事情。

00:20:01 - Saron Yitbarek：

是不是很有意思。

00:20:03 - Clive Thompson：

这就是为什么存在这么多编程语言，人们不断进取，去做别人做不到的事。

00:20:11 - Saron Yitbarek：

这也是为什么我对开发者和编程语言之间的关系很感兴趣，我们对这些工具有很强的依赖性。为什么呢？

00:20:22 - Clive Thompson：

有几个原因。一个是有时你学习你的第一个编程语言完全是一场意外，有点像你的初恋。

00:20:30：

我觉得不同性格的人，也会匹配不同类型的编程语言。例如 Facebook 是用 PHP 设计的。PHP 是有点像毛球，它很不规则，它的成长断断续续，Facebook 也有点这种感觉。

00:20:49：

与此相反，来自谷歌的伙计决定：“我们想要一个超高性能的语言，因为在谷歌我们的东西都高速运行着，维护着万亿级的用户吞吐。”

00:21:02：

因此他们决定开发一个 Go 语言，Go 非常适合高性能计算。

00:21:08 - Saron Yitbarek：

让我们深入一点。作为一个开发者，我有自己的个性，我是不是对一部分编程语言有天然的喜欢呢？或者我工作用的编程语言可能会影响我的个性？

00:21:25 - Clive Thompson：

两者肯定都存在。但我确实认为当你遇到你喜欢的编程语言的时候，有一种强烈的共鸣感。你上计算机课程时学习了必修语言：他们都教 Java，有时会多教一门 JavaScript 或 Python。

00:21:46：

问题是，你被强制要求，所以你学了它。但当你有选择余地时会怎么样呢？这就是你真正看到一个人的那种情感或心理风格是如何倾向于一门语言的地方，因为我和一个人谈过，他试着学了一堆 JavaScript。

00:22:03：

这是个看起来有点丑的语言，它简直是花括号的噩梦。所以他试了又试，试了又试，失败了又失败。直到有一天他看到朋友在用 Python。在他看起来，这是多么的纯净和美妙的语言。因为他是个作家，而 Python 被认为是一个书写型的编程语言，缩进使一切都易于阅读。

00:22:28 - Clive Thompson：

它和他一拍即合，主要在于 Python 的工作方式和外观，漂亮的排版打动了他。

00:22:39 - Saron Yitbarek：

和 Clive 的交流让我意识到，有一些编程语言是硬塞给我们的。我说的是那些古老的编程语言，已经类似于拉丁语了。

00:22:53：

其实我们也有很多选择，去选择适合我们个性的编程语言。如果你想知道最新的东西有哪些，你去问问开发者们周末在用什么就知道了。

00:23:05：

下面是我们对话的更多内容：

00:23:08 - Clive Thompson：

当我问人们：“你闲暇的时候做什么？”回答肯定是些稀奇古怪的东西。我想实际上其中一个好的，最值得称颂的开发者的特点，就是他们是富有好奇心。

00:23:22：

我知道有人会说，“我要学习 Erlang了，就是为了好玩。”

00:23:26 - Saron Yitbarek：

我尝试想象人们在周末开发这些项目，项目不是最重要的，他们在学习工具，编程语言才是重要的事情。这才是他们真的想要的状态。

00:23:41 - Clive Thompson：

确切的说，你将看到为什么大家不停的重复迭代开发这些日历和待办事项，因为这是一个快速的学习方法。但需要指出的是，编程语言做了什么以及如何工作都与我们没关系，我只需要尽可能的构建我的东西。

00:23:56：

他们想知道用那样的编程语言思考是什么感觉。是不是会感觉很轻松、刺激、游刃有余？我目前的使用的语言没这个感觉，是不是入门之后一切事情都变得简单了？

00:24:13 - Clive Thompson：

很有可能你遇到一个新语言后会非常兴奋，想起来都很兴奋。

00:24:20 - Saron Yitbarek：

我是一个 Ruby 从业者，作为 Ruby on Rails 开发者我非常自豪，我想大概是两年前，另一个非常著名的 Ruby 开发者，Justin Serrals 做了一个非常好的演讲，倡导编程语言从实用角度出发，没有必要那么性感。

00:24:41：

他的观点是，Ruby 之所以是一个令人兴奋的编程语言的原因在于它很新，而且差不多几年前都已经得到印证了，它已经不需要更新什么了。它已经是一个稳定、成熟的编程语言了。不过因为它的成熟，开发者对它也就不那么兴奋，我们逐步把目光转移到新的花样来了。

00:25:05：

从某个意义上说，很有可能我们的好奇心会扼杀了一个编程语言，或者让它变得庸俗，而这与编程语言本身的好坏没有关系。

00:25:18 - Clive Thompson：

我认为这是完全正确的。事实上，你看到的开发者这个极度好奇心和自学欲望的特点，会让他们不断地寻找新鲜事物。并用这种语言去复制其他语言已经基本做得很好的东西。

00:25:37 - Saron Yitbarek：

是的。

00:25:37 - Clive Thompson：

就是这样，好奇心有好处，同时也是一个陷阱。

00:25:43 - Saron Yitbarek：

是的，说的很好。

00:25:49：

有时我们的好奇心可能是一个陷阱，但是它也是编程语言革命的动力。开发每个新编程语言的时候他们会说，“有没有别的可能？”它们出现的原因在于，开发人员想要做不一样的事情。

00:26:06：

我们想要全新的表达方式。

00:26:08 - 葛丽丝·哈伯：

我向你们承诺一些事情。

00:26:11 - Saron Yitbarek：

我想葛丽丝·哈伯想在这儿最后讲两句。

00:26:15 - 葛丽丝·哈伯：

在未来 12 个月里，你们谁要是说我们一直都是这么做的，我将会瞬间实质化在你的旁边，然后我 24 小时围绕着你。我倒是要看看我能不能引起你的注意。我们不能再相信那句话，这是很危险的。

00:26:34 - Saron Yitbarek：

葛丽丝的故事和第一款编译器提醒我们，只要能可以找到表达方法，我们总有更好的办法做事情。

00:26:43：

不管编程语言有多抽象，不管我们在机器的 1 和 0 高位还是低位浮动，我们都需要确保它是一个明智选择。我们选择一个语言，是让它帮助我们的想法更容易表达出来。

00:27:03：

如果你想更深一步学习编程语言和和编译器，你不会很孤独，我们收集了一些很有用的文档帮你深入学习。敬请在我们节目下面留言。请查看 redhat.com/commandlineheroes

00:27:20：

下一期节目，我们将关注开源贡献者的艰辛之路。那些维护者的真实奋斗生活是什么样的？我们如何提出第一个拉取请求？

00:27:32：

我们将带你们简单认识开源贡献。

00:27:39：

代码英雄是红帽的原创播客。你可以在苹果播客、谷歌播客以及其他可能的地方免费收听这个节目。

00:27:48：

我是 Saron Yitbarek，坚持编程，下期再见。

什么是 LCTT SIG 和 LCTT LCRH SIG

LCTT SIG 是 LCTT 特别兴趣小组 Special Interest Group ，LCTT SIG 是针对特定领域、特定内容的翻译小组，翻译组成员将遵循 LCTT 流程和规范，参与翻译，并获得相应的奖励。LCRH SIG 是 LCTT 联合红帽（Red Hat）发起的 SIG，当前专注任务是《代码英雄》系列播客的脚本汉化，已有数十位贡献者加入。敬请每周三、周五期待经过我们精心翻译、校对和发布的译文。

欢迎加入 LCRH SIG 一同参与贡献，并领取红帽（Red Hat）和我们联合颁发的专属贡献者证书。

via: https://www.redhat.com/en/command-line-heroes/season-2/hello-world

作者：Red Hat 选题：bestony 译者：guevaraya 校对：acyanbird，wxy

本文由 LCRH 原创编译，Linux中国 荣誉推出

根据一位理论物理学家的说法，由于创建和存储数字信息所使用的能源和资源数量，数据应该被视为物理的，而不仅仅是看不见的一和零。

一位大学学者建议，数字内容应该与气体、液体、等离子体和固体一样，被视为第五种物质状态。

英国朴茨茅斯大学高级讲师、发表在《AIP Advances》杂志上的《信息灾难》一文的作者 Melvin Vopson 称，由于以物理和数字方式创建、存储和分发数据所使用的能量和资源，数据已经发生了演变，现在应该被视为质量。

Vopson 还声称，数字比特正在走向压倒地球的道路，最终将超过原子的数量。

给数字信息分配质量的想法建立在一些现有数据点的基础之上。Vopson 引用了 IBM 的一项估计，发现数据每天以 2.5 万亿字节的速度产生。他还将每英寸超过 1 太比特 terabit 的数据存储密度考虑在内，将比特的大小与原子的大小进行比较。

假设数据生成量每年增长 50%，根据宣布 Vopson 研究的媒体发布，“比特的数量将在大约 150 年内等于地球上的原子数量。”

新闻稿中写道：“大约 130 年后，维持数字信息创造所需的动力将等于地球上目前产生的所有动力，到 2245 年，地球上一半的质量将转化为数字信息质量。”

Vopson 补充说，COVID-19 大流行正在提高数字数据创造的速度，并加速这一进程。

他警告说，一个饱和点即将到来：“即使假设未来的技术进步将比特大小降低到接近原子本身的大小，这个数字信息量所占的比重将超过地球的大小，从而导致我们所定义的‘信息灾难’。”Vopson 在论文中写道。

“我们正在一点一点地改变这个星球，这是一场看不见的危机，”Vopson 说，他是希捷科技公司的前研发科学家。

Vopson 并不是一个人在探索，信息并不是简单的不可察觉的 1 和 0。根据发布的消息，Vopson 借鉴了爱因斯坦广义相对论中的质能对比；将热力学定律应用于信息的 Rolf Landauer 的工作；以及数字比特的发明者 Claude Shannon 的工作。

“当一个人将信息内容带入现有的物理理论中时，这几乎就像物理学中的一切都多了一个维度，”Vopson 说。

他的论文总结道，随着增长速度似乎不可阻挡，数字信息生产“将消耗地球上大部分的电力能源，从而导致道德和环境问题。”他的论文总结道。

有趣的是，除此以外，Vopson 还提出，如果像他所预测的那样，未来地球的质量主要由信息位组成，并且有足够的动力创造出来（不确定），那么“可以设想未来的世界主要由计算机模拟，并由数字比特和计算机代码主导，”他写道。

via: https://www.networkworld.com/article/3570438/information-could-be-half-the-worlds-mass-by-2245-says-researcher.html

作者：Patrick Nelson 选题：lujun9972 译者：wxy 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出