有人喜歡創造世界，他們做了開發者；有的人喜歡開發者，他們做了測驗員，什么是軟體測驗？軟體測驗就是一場本該在用戶面前發生的災難提前在自己面前發生了，這會讓他們生出一種救世主的感覺，拯救了用戶，也就拯救者這個軟體，避免了他們被卸載的命運，
一.我和bug的故事
我目前是 Pilot.com 的一位高級工程師，負責給創業公司提供自動記賬服務，在此之前，我曾是 Dropbox 的桌面客戶端組的成員，我今天將分享關于我當時作業的一些故事，更早之前，我是 Recurse Center 的導師，給身在紐約的程式員提供臨時的訓練環境，在成為工程師之前，我在大學攻讀天體物理學并在金融界作業過幾年，
但這些都不重要——關于我你唯一需要知道的是，我愛 bug，我愛 bug 因為它們有趣，它們富有戲劇性，除錯一個好的 bug 的程序可以非常迂回曲折，一個好的 bug 像是一個有趣的笑話或者或者謎語——你期望看到某種結果，但卻事與愿違，
在這個演講中我會給你們講一些我曾經熱愛過的 bug，解釋為什么我如此愛 bug，然后說服你們也同樣去熱愛 bug，
栗子1：
這是我在 Dropbox 作業時遇到的一個 bug，你們或許聽說過，Dropbox 是一個將你的檔案從一個電腦上同步到云端和其他電腦上的應用，
這是個極度簡化的 Dropbox 架構圖，桌面客戶端在你的電腦本地運行，監聽檔案系統的變動，當它檢測到檔案改動時，它讀取改變的檔案，并把它的內容 hash 成 4 MB 大小的檔案塊，這些檔案塊被存放在后端一個叫做塊服務器blockserver的巨大的鍵值對資料庫key-value store中，
當然，我們想避免多次上傳同一個檔案塊，可以想見，如果你在撰寫一份檔案，你應該大部分時候都在改動檔案最底部——我們不想一遍又一遍地上傳開頭部分，所以在上傳檔案塊到塊服務器之前之前，客戶端會先和一個負責管理元資料和權限等等的服務器溝通，客戶端會詢問這個元資料服務器metaserver它是需要這個檔案塊，還是已經見過這個檔案塊了，元資料服務器會回傳每一個檔案塊是否需要上傳，
所以這些請求和回應看上去大概是這樣：客戶端說“我有一個改動過的檔案，分為這些檔案塊，它們的 hash 是 ‘abcd,deef,efgh’，服務器回應說“我有前兩塊，但需要你上傳第三塊”，然后客戶端會把那個檔案塊上傳到塊服務器，
這是問題的背景，下面是 bug，
有時候客戶端會提交一個奇怪的請求：每個 hash 值應該包含 16 個字母，但它卻發送了 33 個字母——所需數量的兩倍加一，服務器不知道該怎么處理它，于是會拋出一個例外，我們收到這個例外的報告，于是去查看客戶端的記錄檔案，然后會看到非常奇怪的事情——客戶端的本地資料庫損壞了，或者 python 拋出 MemoryError，沒有一個合乎情理的，
如果你以前沒見過這個問題，可能會覺得毫無頭緒，但當你見過一次之后，你以后每次看到都能輕松地認出它來，給你一個提示：在那些 33 個字母的字串中，l 經常會代替逗號出現，其他經常出現的字符是：
英文逗號的 ASCII 碼是 44，l 的 ASCII 碼是 108，它們的二進制表示如下：
你會注意到 l 和逗號只差了一位，問題就出在這里：發生了位反轉，桌面客戶端使用的記憶體中的一位發生了錯誤，于是客戶端開始向服務器發送錯誤的請求，
這是其他經常代替逗號出現的字符的 ASCII 碼：
我愛這個 bug 因為它證明了位反轉是可能真實發生的事情，而不只是一個理論上的問題，實際上，它在某些情況下會比平時更容易發生，其中一種情況是用戶使用的是低配或者老舊的硬體，而運行 Dropbox 的電腦很多都是這樣，另外一種會造成很多位反轉的地方是外太空——在太空中沒有大氣層來保護你的記憶體不受高能粒子和輻射的影響，所以位反轉會十分常見，
在剛才那種情況下，Dropbox 并不需要處理位反轉，出現記憶體損壞的是用戶的電腦，所以即使我們可以檢測到逗號字符的位反轉，但如果這發生在其他字符上我們就不一定能檢測到了，而且如果從硬碟中讀取的檔案本身發生了位反轉，那我們根本無從得知，我們能改進的地方很少，于是我們決定無視這個例外并繼續程式的運行，這種 bug 一般都會在客戶端重啟之后自動解決，
不常見的 bug并不代表它不會發生，
這是我最喜歡的 bug 之一，有幾個原因，第一，它提醒我注意不常見和不可能之間的區別，當規模足夠大的時候，不常見的現象會以值得注意的頻率發生，
覆寫面廣的 bug
第二個讓我喜歡的地方是它覆寫面非常廣，每當桌面客戶端和服務器交流的時候，這個 bug 都可能悄然出現，而這可能會發生在系統里很多不同的端點和組件當中，這意味著許多不同的 Dropbox 工程師會看到這個 bug 的各種版本，你第一次看到它的時候，你 真的 會滿頭霧水，但在那之后診斷這個 bug 就變得很容易了，而調查程序也非常簡短：你只需找到中間的字母，看它是不是個 l，
文化差異
這個 bug 的一個有趣的副作用是它展示了服務器組和客戶端組之間的文化差異，有時候這個 bug 會被服務器組的成員發現并展開調查，如果你的 服務器 上發生了位反轉，那應該不是個偶然——這很可能是記憶體損壞，你需要找到受影響的主機并盡快把它從集群中移除，不然就會有損壞大量用戶資料的風險，這是個事故，而你必須迅速做出反應，但如果是用戶的電腦在破壞資料，你并沒有什么可以做的，
共享你的bug
如果你在除錯一個難搞的 bug，特別是在大型系統中，不要忘記跟別人討論，也許你的同事以前就遇到過類似的 bug，若是如此，你可能會節省很多時間，就算他們沒有見過，也不要忘記在你解決了問題之后告訴他們解決方法——寫下來或者在組會中分享，這樣下次你們組遇到類似的問題時，你們都會早有準備，
Bug 如何幫助你進步
Recurse Center
在加入 Dropbox 之前，我曾在 Recurse Center 作業，它的理念是建立一個社區讓正在自學的程式員們聚到一起來提高能力，這就是 Recurse Center 的全部了：我們沒有大綱、作業、截止日期等等，唯一的前提條件是我們都想要成為更好的程式員，參與者中有的人有計算機學位但對自己的實際編程能力不夠自信，有的人已經寫了十年 Java 但想學 Clojure 或者 Haskell，還有各式各樣有著其他的背景的參與者，
我在那里是一位導師，幫助人們更好地利用這個自由的環境，并參考我們從以前的參與者那里學到的東西來提供指導，所以我的同事們和我本人都非常熱衷于尋找對成年自學者最有幫助的學習方法，
刻意練習
在學習方法這個領域有很多不同的研究，其中我覺得最有意思的研究之一是刻意練習的概念，刻意練習理論意在解釋專業人士和業余愛好者的表現的差距，它的基本思想是如果你只看內在的特征——不論先天與否——它們都無法非常好地解釋這種差距，于是研究者們，包括最初的 Ericsson、Krampe 和 Tesch-Romer，開始尋找能夠解釋這種差距的理論，他們最終的答案是在刻意練習上所花的時間，
他們給刻意練習的定義非常精確：不是為了收入而作業，也不是為了樂趣而玩耍，你必須盡自己能力的極限，去做一個和你的水平相稱的任務（不能太簡單導致你學不到東西，也不能太難導致你無法取得任何進展），你還需要獲得即時的反饋，知道自己是否做得正確，
這非常令人興奮，因為這是一套能夠用來建立專業技能的系統，但難點在于對于程式員來說這些建議非常難以實施，你很難知道你是否處在自己能力的極限，也很少有即時的反饋幫助你改進——有時候你能得到任何反饋都已經算是很幸運了，還有時候你需要等幾個月才能得到反饋，對于在 REPL 中做的簡單的事情你可以很快地得到反饋，但如果你在做一個設計上的決定或者技術上的選擇，你在很長一段時間里都無法得到反饋，
但是在有一類編程作業中刻意練習是非常有用的，它就是 debug，如果你寫了一份代碼，那么當時你是理解這份代碼是如何作業的，但你的代碼有 bug，所以你的理解并不完全正確，根據定義來說，你正處在你理解能力的極限上——這很好！你馬上要學到新東西了，如果你可以重現這個 bug，那么這是個寶貴的機會，你可以獲得即時的反饋，知道自己的修改是否正確，
像這樣的 bug 也許能讓你學到關于你的程式的一些小知識，但你也可能會學到一些關于運行你的代碼的系統的一些更復雜的知識，我接下來要講一個關于這種 bug 的故事，
栗子2：
這也是我在 Dropbox 作業時遇到的 bug，當時我正在調查為什么有些桌面客戶端沒有像我們預期的那樣持續發送日志，我開始調查客戶端的日志系統并且發現了很多有意思的 bug，我會挑一些跟這個故事有關的 bug 來講，
和之前一樣，這是一個非常簡化的系統架構，
桌面客戶端會生成日志，這些日志會被壓縮、加密并寫入硬碟，然后客戶端會間歇性地把它們發送給服務器，客戶端從硬碟讀取日志并發送給日志服務器，服務器會將它解碼并存盤，然后回傳 200，
如果客戶端無法連接到日志服務器，它不會讓日志目錄無限地增長，超過一定大小之后，它會開始洗掉日志來讓目錄大小不超過一個最大值，
最初的兩個 bug 本身并不嚴重，第一個 bug 是桌面客戶端向服務器發送日志時會從最早的日志而不是最新的日志開始，這并不是很好——比如服務器會在客戶端報告例外的時候讓客戶端發送日志，所以你可能最在乎的是剛剛生成的日志而不是在硬碟上的最早的日志，
第二個 bug 和第一個相似：如果日志目錄的大小達到了上限，客戶端會從最新的日志而不是最早的日志開始洗掉，同理，你總是會丟失一些日志檔案，但你大概更不在乎那些較早的日志，
第三個 bug 和加密有關，有時服務器會無法對一個日志檔案解碼（我們一般不知道為什么——也許發生了位反轉），我們在后端沒有正確地處理這個錯誤，而服務器會回傳 500，客戶端看到 500 之后會做合理的反應：它會認為服務器停機了，所以它會停止發送日志檔案并且不再嘗試發送其他的日志，
對于一個損壞的日志檔案回傳 500 顯然不是正確的行為，你可以考慮回傳 400，因為問題出在客戶端的請求上，但客戶端同樣無法修復這個問題——如果日志檔案現在無法解碼，我們后也永遠無法將它解碼，客戶端正確的做法是直接洗掉日志檔案然后繼續運行，實際上，這正是客戶端在成功上傳日志檔案并從服務器收到 200 的回應時的默認行為，所以我們說，好——如果日志檔案無法解碼，就回傳 200，
所有這些 bug 都很容易修復，前兩個 bug 出在客戶端上，所以我們在 alpha 版本修復了它們，但大部分的客戶端還沒有獲得這些改動，我們在服務器代碼中修復了第三個 bug 并部署了新版的服務器，
激增
突然日志服務器集群的流量開始激增，客服團隊找到我們并問我們是否知道原因，我花了點時間把所有的部分拼到一起，
在修復之前，這四件事情會發生：
日志檔案從最早的開始發送
日志檔案從最新的開始洗掉
如果服務器無法解碼日志檔案，它會回傳 500
如果客戶端收到 500，它會停止發送日志
一個存有損壞的日志檔案的客戶端會試著發送這個檔案，服務器會回傳 500，客戶端會放棄發送日志，在下一次運行時，它會嘗試再次發送同樣的檔案，再次失敗，并再次放棄，最終日志目錄會被填滿，然后客戶端會開始洗掉最新的日志檔案，而把損壞的檔案繼續保留在硬碟上，
這三個 bug 導致的結果是：如果客戶端在任何時候生成了損壞的日志檔案，我們就再也不會收到那個客戶端的日志了，
問題是，處于這種狀態的客戶端比我們想象的要多很多，任何有一個損壞檔案的客戶端都會像被關在堤壩里一樣，無法再發送日志，現在這個堤壩被清除了，所有這些客戶端都開始發送它們的日志目錄的剩余內容，
我們的選擇
好的，現在檔案從世界各地的電腦如洪水般涌來，我們能做什么？（當你在一個有 Dropbox 這種規模，尤其是這種桌面客戶端的規模的公司作業時，會遇到這種有趣的事情：你可以非常輕易地對自己造成 DDoS 攻擊），
當你部署的新版本發生問題時，第一個選項是回滾，這是非常合理的選擇，但對于這個問題，它無法幫助我們，我們改變的不是服務器的狀態而是客戶端的——我們洗掉了那些出錯檔案，將服務器回滾可以防止更多客戶端進入這種狀態，但它并不能解決根本問題，
那擴大日志集群的規模呢？我們試過了——然后因為處理能力增加了，我們開始收到更多的請求，我們又擴大了一次，但你不可能一直這么下去，為什么不能？因為這個集群并不是獨立的，它會向另一個集群發送請求，在這里是為了處理例外，如果你的一個集群正在被 DDoS，而你持續擴大那個集群，你最侄訓把它依賴的集群也弄壞，然后你就有兩個問題了，
我們考慮過的另一個選擇是減低負載——你不需要每一個日志檔案，所以我們可以直接無視一些請求，一個難點是我們并沒有一個很好的方法來區分好的請求和壞的請求，我們無法快速地判斷哪些日志檔案是舊的，哪些是新的，
我們最終使用的是一個 Dropbox 里許多不同場合都用過的一個解決方法：我們有一個自定義的頭欄位，chillout，全世界所有的客戶端都遵守它，如果客戶端收到一個有這個頭欄位的回應，它將在欄位所標注的時間內不再發送任何請求，很早以前一個英明的程式員把它加到了 Dropbox 客戶端里，在之后這些年中它已經不止一次地起了作用，
認識你的系統
這個 bug 的第一個教訓是要了解你的系統，我對于客戶端和服務器之間的互動有不錯的理解，但我并沒有考慮到當服務器和所有這些客戶端同時互動的時候會發生什么，這是一個我沒有完全搞懂的層面，
了解你的工具
第二個教訓是要了解你的工具，如果出了差錯，你有哪些選項？你能撤銷你做的遷移嗎？你如何知道事情出了差錯，你又如何發現更多資訊？所有這些事情都應該在危機發生之前就了解好——但如果你沒有，你會在危機發生時學到它們并不會再忘記，
功能開關 & 服務器端功能控制
第三個教訓是專門針對移動端和桌面應用開發者的：你需要服務器端功能控制和功能開關，當你發現一個問題時如果你沒有服務器端的功能控制，你可能需要幾天或幾星期來推送新版本或者提交新版本到應用商店中，然后問題才能得到解決，這是個很糟糕的處境，Dropbox 桌面客戶端不需要經過應用商店的審查程序，但光是把一個版本推送給上千萬的用戶就已經要花很多時間，相比之下，如果你能在新功能遇到問題的時候在服務器上翻轉一個開關：十分鐘之后你的問題就已經解決了，
這個策略也有它的代價，加入很多的功能開關會大幅提高你的代碼的復雜度，而你的測驗代碼更是會成指數地復雜化：要考慮 A 功能和 B 功能都開啟，或者僅開啟一個，或者都不開啟的情況——然后每個功能都要相乘一遍，讓工程師們在事后清理他們的功能開關是一件很難的事情（我自己也有這個毛病），另外，桌面客戶端會同時有好幾個版本有人使用，也會加大思考難度，
但是它的好處——啊，當你需要它的時候，你真的是很需要它，
如何去熱愛 bug
我講了幾個我愛的 bug，也講了為什么要愛 bug，現在我想告訴你如何去愛 bug，如果你現在還不愛 bug，我知道唯一一種改變的方法，那就是要有成長型心態，
社會學家 Carol Dweck 做了很多關于人們如何看待智力的研究，她找到兩種不同的看待智力的心態，第一種，她叫做固定型心態，認為智力是一個固定的特征，人類無法改變自己智力的多寡，另一種心態叫做成長型心態，在成長型心態下，人們相信智力是可變的而且可以通過努力來增強，
Dweck 發現一個人看待智力的方式——固定型還是成長型心態——可以很大程度地影響他們選擇任務的方式、面對挑戰的反應、認知能力、甚至是他們的誠信度，
熱愛你的 bug
很多時候有朋友會坐到我身邊說“唉，我覺得我遇到了個奇怪的 Python bug”，然后我會說“太棒了，我 愛 奇怪的 Python bug！” 首先，這百分之百是真的，但更重要的是，我這樣是在對參與者強調，找到讓自己覺得戰勝困難的事情是一種成就，而他們做到了這一點，所以為他們豎起大拇指，真棒！
寫在最后：
感謝您的觀看，如有不足之處，歡迎批評指正，
在這里推薦一個軟體測驗交流群，QQ:642830685,群中會不定期的分享軟體測驗資源，測驗面試題以及測驗行業資訊，大家可以在群中積極交流技術，還有大佬為你解答技術問題，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/251990.html
標籤：其他