【伯乐在线导读】：2010 年 5 月 21 日吃豆人游戏 30 周年，Google 首页在上午 9 点上线了一个可交互的涂鸦游戏。几个小时内，这个游戏就让全世界都为之疯狂。不过涂鸦团队开始陆续收到一个诡异 Bug 的报告。作者在本文中分享了这个 Bug 背后的有趣故事。

2010 年 5 月 21 日的那个周五对大多数人来说，可能都只是一个普通的周五而已。但对我来说，那一天可以说是最不同寻常的周五了。

那天我的推特瘫痪了。那天我跟我父亲说了最后一句话。那天我让数亿人体验了我做的东西。但是这里的故事跟所有这些都没有关系。本文讲述了我是怎样让一些人觉得他们疯了的。

2010 年我在 Google 工作，并被拉进了吃豆人涂鸦游戏的研究和编程工作中。吃豆人涂鸦游戏是 Google 为了庆祝这款经典电子游戏诞生 30 周年而推出的，而且会放在 Google 的主页上。在那天之前，我花了几个月时间从头写完了所有的代码（没有任何效仿）。周五早上，太平洋时间 9 点，我们像全世界揭开了它的面纱。

这是首款像样的交互型涂鸦，也是第一个能真正跟 Google 搜索框争夺注意力的东西。所以，在众多设计决策中，我们需要注意的是如何在推广这款涂鸦游戏和便于人们完成搜索并继续他们的生活之间达到平衡。

在一番深思熟虑之后，我们做出了以下几个决定：

如果访客打开 Google 主页超过了 10 秒钟就自动开始游戏（当然啦，如果他们点击这个涂鸦，或者按下特别的“投币”按钮就能提前开始玩了）

• 游戏默认是开启声音的（否则很多人可能意识不到这个游戏是有声音的，并损失了很多游戏乐趣）

• 吃豆人涂鸦游戏会在 Google 主页上保持 48 小时，而不是通常的 24 小时

来势汹汹？可能吧。我们主页上的可是吃豆人啊！我们对此感到非常骄傲，而且希望人们——他们还不习惯可以玩的 Google 主页——能注意到它，能玩得开心。

即使在发布之前，那天已经像个不寻常的周五了。我们之前从未做过像个涂鸦一样的东西。我和团队里的一些人通宵拍了照，还准备了一个吃豆人的内部比赛版本。就我个人而言，我还是吓坏了。我是用户体验团队的一名设计师。诚然，我的代码通过了所有适当的审查，但是我还是不敢相信它能——一字不差地——出现在 Google 最有价值的资产上。

我们在上午 9 点打开开关。几个小时内吃豆人游戏就让全世界都为之疯狂。很快，我收到了如山洪般的反馈，以致于我根本不可能跟得上收到反馈的速度。我还突然被要求去参加新闻采访。上面提到“我的推特瘫痪了”，其实可能是我把事情自私地过度简化了（如果没有整个优秀的团队支持着我，这一切都不会发生），但是我也不认为有夸张的成分在里面。一个小时内，随着越来越多关于 Google 吃豆人的推特消息涌进来，推特开始向我们发送这样的消息：

“推特过载了”

但是在所有的兴奋之中——兴奋的感觉被缺觉加强了，我们开始收到一个奇怪问题的报告。即，即使有些人没有在玩吃豆人，也能听到它的声音。

我们最初忽略了这些投诉——“告诉他们关掉 Google 主页就好了”——但是这么做并没有用。在四处研究、绞尽脑汁之后，我们发现罪魁祸首比我们想象得复杂，而且更迷人。

2010 年是火狐最好的一年。使用火狐浏览器的一部分人安装了一个叫 CoolPreviews 的扩展，这样将鼠标悬停在链接上就可以快速预览网页。

在火狐浏览器打开的同时，该扩展就会启动。并且在用户不知情的情况下，它会立即在后台打开一个隐形网页，也就是 Google 主页。

你很可能已经把事情发生的经过串起来了。在那个周五，google.com 自动打开有声音的吃豆人涂鸦游戏。如果你使用了装有 CoolPreviews 的火狐浏览器，该插件就会在你启动浏览器的时候，消无声息地在后台打开 Google 主页，10 秒钟之后……会莫名其妙地出现游戏声音。

想象一下，你在周五早上坐下来，打开电脑。对你来说，这个周五本没有什么异常的地方。你打开游览器；但可能并不了解 CoolPreviews，甚至是插件或者扩展的概念；不需要使用 Google，或者根本不知道 Google；可能也不知道用了什么浏览器——或者什么是浏览器。事实上，你甚至可能都没在用浏览器；有可能它最小化了，默默地缩在屏幕下方的工具栏里。可能你正在查看邮箱，或者为今天的第一轮纸牌游戏热身。

你干什么都无所谓。十秒钟之后，你会从电脑的扬声器中——知道怎么调整音量吗？知道电脑有扬声器吗？——听到声音。

这是一个隐形吃豆人游戏的警报声，它以最不寻常的方式渗透到你的电脑里了。

重复。

可能你经历过被朋友或者家庭成员用电脑问题纠缠的情况。他们不如你懂技术，再简单不过的方法都能解决这些问题。你可能会轻蔑地问“你确定连上鼠标了吗？”、“老天，试试关掉大写锁定。”

现在来想象一下：如果他们其中之一在那个周五告诉你，他们的电脑莫名其妙发出警报一样的声音，你会怎么说？

你会告诉他们，他们疯了。他们可能也想过自己一定是疯了。这全都怪我的代码。

我不太记得我们到底是怎么弄明白的。但是一个小时内，我们编写了代码并立即发布了一个双重修复：

我们添加了一个可见的声音开关，允许随意开启或者关闭游戏的声音：

前后对比。注意左下角的声音按钮。

• 我们没有删除自动开始的设定，而是修改了代码；这样在访问者与游戏有某种互动之前是不会有声音的

/**
* Process a new Pac-Man direction requested by player
* using arrow keys or touch.
* @param {number} newDir New direction.
*/
PacManActor.prototype.processRequestedDirection = function(newDir) {
  // Enable sound as long as the user hasn’t previously
  // disabled it by clicking the sound icon.
  if (!pacMan.userDisabledSound && !google.pacManSound) {
    google.pacManSound = true;
    pacMan.updateSoundIcon();
  }

无论什么时候遇到 bug，试着回答以下四个简单的问题是很自然的：

• 发生了什么？

• 怎么修复它？

• 怎样避免它再次发生？

• 责任人是谁？

这一次，前三个问题很容易：我们弄清楚、打好补丁、把这次的快速修复作为未来每一个涂鸦的最佳做法。

就最后一个问题来说…“责任人是谁？”很少是个好问题，但是一起来考虑一下：

这是我们的错。我们本应该预见到这个问题的，对吧？但是看看所有这些巧合的联系：一个特定的浏览器，一个特定的异常插件，音量开启，要等 10 秒问题才会发生。要想预见到这个问题需要多少想象力？

显然，CoolPreviews 有一些拙劣的编程做法！我其实不确定他们为什么要通过在后台打开 Google 主页来启动——可能仅仅是随机的默认项？或者是一种检测网络连接的方法？但是再次声明， Google 主页能承受很大的流量；并且关键地是，它之前从来不会发出任何声音。所以假设在后台打开 Google 主页没有任何风险并不离谱。

一开始安装 CoolPreviews 是用户的错。如果一个问题是由于插件导致的，那卸载这个插件是用户的责任。但是，你觉得一个人能意识到，导致电脑发出声音的罪魁祸首是一个随机的预览扩展吗？

浏览器开发商不该允许插件做类似疯狂的事情。最近一段时间，浏览器很可能都能做到这一点。但是当时，网络要更开放一点……毕竟，这个 bug 并不会威胁到你的隐私或者数据安全。

针对“责任人是谁？”这个问题，我能想到的最好答案是：网络的复杂性。网络已经出现了一段时间，涉及了很多利益相关者。网络的开放性和宽容性，以及它的某些特点就这样……自然而然地产生了。

想要因为网络的复杂性而惩罚它，就像 Xerxes 因为大海吞没了他差劲的桥就鞭打大海一样。远离网络转向本国客户可能就是用一组问题来交换另一组问题。想要降低网络的复杂性……事实上，很多聪明人把它作为工作或者闲暇时的消遣。

无论怎样，都需要修复 bug。

修复 bug 的一种方式是建立复杂的机制，来提前识别问题并避免它们发生。当然，有时候你别无选择，这是唯一的方法。任何与用户数据、隐私、安全或者金融信息相关的事物都是禁区——需要谨慎地检查并控制它们，没有商量的余地。

但是还有我们正在讨论的这类情况。我已经在 Medium 上写过其他奇怪的 bug，比如消失的 Polish S，以及 25 岁的系统字体从它的像素化坟墓中复活……现在是在小部分电脑上出现吃豆人的奇怪噪音。你无法完全预见那些远不是在你的服务器上发生的 bug，那些后果不是很严重的 bug。你可以试着阻止这些 bug 发生，但是假设这些 bug 会发生，并把精力用在建设基础设施来进行 bug 的捕捉和尽快修复上会更容易。

我认为，修复吃豆人 bug 的真正成就是两个紧凑循环：第一，支持团队和产品部门的交流……第二，有预见能力的“热点推送”基础设施能让我们的修复在几分钟内迅速实施，这对 Google 这种规模的公司来说是非常惊人的。

2010 年的这个周五对我来说是非同寻常的，但是我也知道我的工作让这一天对许多其他人变得非同寻常。有些人想起了他们在 80 年代早期玩吃豆人的时光。有些人对 HTML 的可能性感到兴奋。有些人只是玩得很开心然后继续生活。

我对那一天最喜欢的反应之一是——我们将我小时候喜爱的那种游戏厅精神带到了 2010 年的 48 小时当中。

“我在这个咖啡店里同时听到了三个吃豆人的声音。我有点爱你， Google 。”

我希望你不是遇到这个 bug 的人之一。如果你遇到了，而且我的代码把你吓坏了，抱歉。但是只要我还在写代码，总会有 bug 需要解决，无论是我的还是别人的。识别 bug、将它们按重要性排序，以及在发布之前（需要时间）或者发布之后（对人们产生影响）排除这些 bug ，在这三者之中找到一个平衡点将仍然是我面临的更大挑战之一。

2010 年另外一个有趣的部分是，我还得重新介绍吃豆人原作代码的一个 bug……不过那是另一篇完全不同的文章了。

同时，我也想听听你的 bug 故事。在你需要负一部分责任的 bug 中，最奇怪、最意外、最酷的是哪个？把这类事情当做最好要修复和忘掉错误或者失败很难。但是他们也告诉了我们一些事实，关于我们所创造的这个世界的事实，以及加强了其基础的、奇妙的、疯狂的复杂性。

感谢 Ryan Germick 和 Kris Hom 在这个涂鸦项目上的合作。想了解 Google 吃豆人的更多秘密？请观看 Google I/O 2011 的一个访谈。创造一个不可能预测的情景需要多少情形交织在一起？如果你想要阅读一篇相关的好故事，看看 Stanisław Lem 杰出的小说《机会链》（The Chain of Chance）。

这篇文章里的照片拍摄于发布前的那个通宵。感谢 Dan Pupius 和 Jamie Talbot 对这篇文章提供的帮助。

未经允许请勿转载：程序喵 » 差点毁掉谷歌吃豆人涂鸦游戏的 bug