幾乎毀掉谷歌吃豆人塗鴉遊戲的 bug
【伯樂線上導讀】：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；可能也不知道用了什麼瀏覽器——或者什麼是瀏覽器。事實上，你甚至可能都沒在用瀏覽器；有可能它最小化了，默默地縮在螢幕下方的工具欄裡。可能你正在檢視郵箱，或者為今天的第一輪紙牌遊戲熱身。
你幹什麼都無所謂。十秒鐘之後，你會從電腦的揚聲器中——知道怎麼調整音量嗎？知道電腦有揚聲器嗎？——聽到聲音。
這是一個隱形吃豆人遊戲的警報聲，它以最不尋常的方式滲透到你的電腦裡了。
重複。
可能你經歷過被朋友或者家庭成員用電腦問題糾纏的情況。他們不如你懂技術，再簡單不過的方法都能解決這些問題。你可能會輕蔑地問“你確定連上滑鼠了嗎？”、“老天，試試關掉大寫鎖定。”
現在來想象一下：如果他們其中之一在那個週五告訴你，他們的電腦莫名其妙發出警報一樣的聲音，你會怎麼說？
你會告訴他們，他們瘋了。他們可能也想過自己一定是瘋了。這全都怪我的程式碼。
我不太記得我們到底是怎麼弄明白的。但是一個小時內，我們編寫了程式碼並立即釋出了一個雙重修復：
我們添加了一個可見的聲音開關，允許隨意開啟或者關閉遊戲的聲音：
前後對比。注意左下角的聲音按鈕。
- 我們沒有刪除自動開始的設定，而是修改了程式碼；這樣在訪問者與遊戲有某種互動之前是不會有聲音的
| 123456789101112 | /** * 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 對這篇文章提供的幫助。