為啥程序會有bug？
這是一篇半娛樂性的吐槽文章，權(quán)當(dāng)給廣大技術(shù)人員解解悶。
哈哈哈，然后我要開始講一個經(jīng)常在發(fā)生的事實了。（程序員們可能會感到一些不適）
99.999999999%做技術(shù)的都會被問到或者被吐槽到：“你的程序怎么又出bug了！”
圖片來源于網(wǎng)絡(luò)，版權(quán)歸原作者所有
反正，我作為程序員的內(nèi)心世界是：如同一萬只草泥馬飛奔而過，難以壓抑內(nèi)心的激動，每次都差點忍不住想說“你寫篇幾百字的作文還有錯別字呢，我碼個幾萬行的代碼還不允許出錯了？“
可能同樣是做技術(shù)的你此時在不斷點頭，哈哈。
但是這么講畢竟也緩解不了矛盾，我們還是得擺事實講道理不是？
啥都不怕，就怕程序員有文化！
所以，Z哥想來帶你好好分析一下這個事情，當(dāng)你再遇到這個情況的時候，可以拿這些觀點來反駁（不是做技術(shù)的也可以了解下程序員的難處，誰沒個難處呢，多多包容）
什么是Bug
任何一個「問題」的產(chǎn)生，本身是沒有好壞之分的，但是為什么會有的就不被care，甚至還會很喜歡，而有的會被吐槽呢？根本原因是因為產(chǎn)生了利益損失。
比如年前拼多多出問題送了很多無門檻券。
作為一個用戶，自然很喜歡，夸你夸到飛起，怎么會吐槽你呢。但是作為利益損失方，必然破口大罵，害我傾家蕩產(chǎn)！
所以，如果沒有產(chǎn)生利益損失，我想其他人也不會來找你吐槽。
但是「問題」就等于「bug」嗎？我認(rèn)為并不是，「問題」不等于「 bug」。
因為程序員的職責(zé)是什么？拿造房子來比喻的話，我認(rèn)為最核心的工作真的和“搬磚”（非貶義詞）無異，就是根據(jù)設(shè)計師（產(chǎn)品經(jīng)理）設(shè)計好的設(shè)計圖砌磚（編碼），建成和設(shè)計圖紙上一模一樣的建筑。
所以，如果一個東西造出來與設(shè)計不符，那么它可以說是bug或者缺陷（缺斤少兩不完整）。否則，并不是bug，但可以被稱之為「漏洞」（完全沒考慮到的），表示不在預(yù)料之內(nèi)的情況。
之前看到過一個形象的比喻：你家里的窗可以從外面打開，那叫漏洞。你家里的窗打不開，那叫bug。
但是要承認(rèn)，bug是必然存在的。為什么？它是如何出現(xiàn)的呢？
Bug是如何出現(xiàn)的
正如前面所說，程序員做的是“造房子”的事情。這件事完整的步驟分為3步。
- 與產(chǎn)品經(jīng)理討論并確定功能（確定一個可以實現(xiàn)的設(shè)計圖紙）
- 將每個單獨的元件抽象出來（確定施工方案）
- 將相關(guān)的元件實現(xiàn)并進(jìn)行組合，完成建設(shè)（帶上材料開始施工）
第一步，“與產(chǎn)品經(jīng)理討論并確定功能”主要是溝通，靠“看”和“理解”。
但是溝通本身是一個有損耗的過程，特別是在職責(zé)非常明確的組織中，產(chǎn)品經(jīng)理啪啦啪啦講了很多，到實際做的時候你必然還是會去翻閱需求原型、需求文檔之類的重新理解一下。這個時候就是一個非常危險的時期。
比如像下面這個的答案是什么？
▲圖片來源于網(wǎng)絡(luò)，版權(quán)歸原作者所有
答案是17？不對。
我猜你可能沒注意到這些地方。
▲圖片來源于網(wǎng)絡(luò)，版權(quán)歸原作者所有
為了讓你有深刻的印象，這個舉例可能比較刻意和夸張一些，但是我想在你的身邊，由于沒注意到或者理解有誤的現(xiàn)象肯定很常見。
溝通是相互的，這鍋只讓程序員背的話的確太委屈了點。
第二步，“將每個單獨的元件抽象出來”這主要是一個人抽象能力的體現(xiàn)。
但是抽象是啥？抽象是“透過現(xiàn)象看到本質(zhì)”的能力，這個能力理論上是可以無限增長的。隨著你對相關(guān)信息的掌握越多，這個能力會越強(qiáng)，會無限趨近于100%，但永遠(yuǎn)不會真正達(dá)到100%，因為沒人知道怎么才算100%。
所以，當(dāng)你具備的信息沒那么多的時候，是不是就抽象的不是那么合理？不合理會導(dǎo)致什么？雖然不會直接產(chǎn)生bug，但是會更容易產(chǎn)生bug。但是人不都是需要經(jīng)歷這么一個成長的過程么？
可以說，精通一項能力的背后都是踩著無數(shù)的bug過來的。要么在來這個組織之前已經(jīng)踩過了，要么在這個組織里踩。因此，前者的薪資也比后者高。
所以，如果過分苛求沒有bug，等于是在扼殺每個人成長的機(jī)會，并且在透支未來的可能性。人會變得非常保守、不敢嘗試新事物。
但是外部環(huán)境在不斷變化，新事物總會被動的需要去接納（技術(shù)的更新越來越快，趨勢不可逆），然而對新事物的接受能力又得不到鍛煉，一旦遇到這種情況，在接觸新事物的時候會產(chǎn)生更多的問題（欠下的債總要還的）。
第三步，“將相關(guān)的元件實現(xiàn)并進(jìn)行組合，完成建設(shè)”這就是實際的coding過程，而coding是一個主觀的，完全由人主觀掌控的事情。
人畢竟不是機(jī)器，不可能不犯錯，就如前面提到的寫文章的時候出現(xiàn)錯別字一樣。
可能你會說，有測試人員啊，測試的工作不就是通過逆向思維來給程序員查缺補(bǔ)漏嗎？
的確是的，但測試的介入只是降低錯誤率，只是讓不出現(xiàn)bug的概率小數(shù)點后多幾位
，指望發(fā)現(xiàn)100%的問題還是不太現(xiàn)實的。至少在當(dāng)下的條件下是這樣，為什么呢？因為代碼的本質(zhì)是各種邏輯的組合。
比如，一個完整的業(yè)務(wù)流程有10個環(huán)節(jié)，每個環(huán)節(jié)有3種可能性，這是一個什么復(fù)雜度的系統(tǒng)？3 ^ 10 = 59049個分支（理論上存在的可能性數(shù)量），想要100%覆蓋這些場景，付出的成本幾乎是不可接受的。
然而我們實際的系統(tǒng)中遇到的個別場景甚至還要復(fù)雜的多。
其實每個正在運行的系統(tǒng)都有bug，包括我們每天在使用一些熱門系統(tǒng)（玩游戲的小伙伴們肯定熟悉“卡bug”這個詞）。只是這些bug有沒有被執(zhí)行到，有沒有被發(fā)現(xiàn)，被多少人發(fā)現(xiàn)而已。
那么，我們只能舉手投降嗎？那倒不至于，辦法還是有的。
減少bug的慣性想法
首先最容易想到的一點是，增加測試人員。
這也是最容易看得到的“成本”一種方式，畢竟招一個人就得支出一份工資啊。所以，增加測試人員這個方案是最不容易被老板們采納的方案。除非你可以說服這個人力成本的投入小于獲得的價值。
另外，這個方案其實還增加了溝通成本，溝通的「隱性成本」其實非常大，但是往往容易被忽略。（關(guān)于溝通成本，感興趣的可以看我之前寫的《就簡單聊聊溝通效率問題》）
其次會想到的就是程序員代碼寫的嚴(yán)謹(jǐn)一點，仔細(xì)一點啊。這也是一種缺啥補(bǔ)啥的慣性思維。
先撇開到底能不能達(dá)到嚴(yán)謹(jǐn)一點，仔細(xì)一點的目的。那怕達(dá)到了，他會產(chǎn)生什么結(jié)果呢？可能是下面3種。
- 更多的條件驗證
- 更多的單元測試
- 更多的抽象提煉
可以確定的是，這些工作會增加2樣硬性的東西，投入的時間和整體的復(fù)雜度。時間很好理解，我們就來聊聊復(fù)雜度。
一個常識是，越簡單的東西越不容易產(chǎn)生bug。比如1+1=2，出現(xiàn)bug的可能性無非就是加號寫成來減號，1寫成了4之類。但是，1+1=2，并且1*1=1，并且1/1=1，。。。等等這些驗證條件越多，那么由于驗證條件自身的錯誤而產(chǎn)生問題的可能性反而更多。
所以，代碼的復(fù)雜度和產(chǎn)生bug的概率是成正比的，并且具有「邊際效用遞減」的效果。這就意味著，做更多的驗證帶來的收益會越來越小。
因此，這個方案哪怕真能執(zhí)行到位，也不是一個特別好的方案。
那有沒有相對靠譜一些的辦法呢？有，但需要我們換一個角度來看待這個問題。
換一個角度看待bug
既然無法100%避免bug，那我們可以換個角度考慮一下，如何讓解決bug的過程更快，甚至快到你都沒有察覺。
解決bug主要就是做2件事，找到bug的產(chǎn)生點，然后修復(fù)它。
每天都在解決bug的程序員們應(yīng)該知道，這事最費時間的是“找bug”的過程。
因為“修復(fù)bug”是一個技術(shù)性問題，這個對不同人的差異其實是很小的，因為程序員們每天在寫的代碼都是差不多的，非常同質(zhì)化的，況且還有標(biāo)準(zhǔn)答案“文檔”可以參考。比如，都知道string.concat()是拼接，string.split()是分割。該用分割的地方不小心用了拼接，那改掉就好。
但是“找bug”就不是這樣了。比如，你剛剛改完一行代碼后發(fā)布出現(xiàn)的問題，你不用找就知道問題出現(xiàn)在哪。但是讓你排查一個剛接手沒多久的系統(tǒng)肯定是一臉懵逼。
根本原因在于，這個過程不像技術(shù)性問題具有確定性，它是充滿不確定性的，處在一個“混沌”的環(huán)境中。
所以，對待bug的重點就變成了：如何更快的發(fā)現(xiàn)和找到bug。
關(guān)于這點Z哥的建議是：
- 打好日志
- 學(xué)會利用工具
- 每次的迭代規(guī)模盡可能的小
首先，打好日志。日志其實就是我們在編碼的時候安插在程序中“記錄員”，它替我們記錄著我們認(rèn)為容易出現(xiàn)問題的地方所產(chǎn)生的信息。
但是系統(tǒng)無時無刻都在運行著，必然會產(chǎn)生大量的日志信息，如何從這些信息中快速的找到關(guān)鍵信息，就是需要考慮的問題。
另外，如果每個人都隨意的用自己喜歡的記錄日志的方式，那么從風(fēng)格迥異的日志中找你需要的信息就變得很頭疼，時間不一致，格式不一致等等。
所以，要做好打日志這個事情，就需要定義一個標(biāo)準(zhǔn)，比如必須要有時間，包含當(dāng)前上下文的參數(shù)等等。
我們還可以給日志做一下歸類，定義不同的日志級別，在記錄的時候帶上前綴。比如【info】、【warning】、【error】之類。如此一來，平時更著重關(guān)注的就是error級別的信息，而且由于將其他級別的信息剝離了出去，使得這里的數(shù)據(jù)量大大減少，更便于查看。
不過，日志記錄畢竟是一個在做“預(yù)判”，如果日志中沒有記錄到怎么辦呢？這里提醒大家不要先想著怎么調(diào)試。
如果你面對的系統(tǒng)是一個單體應(yīng)用倒還好。如果你面對的是一個大型的分布式系統(tǒng)，調(diào)試的效率低不說，這事你一個人可能還完不成。而且，如果你直接調(diào)試生產(chǎn)環(huán)境的話，說不準(zhǔn)還會產(chǎn)生什么副作用，攤上新的問題。
找bug本質(zhì)上是一個排除法的過程，設(shè)斷點調(diào)試也是如此。但是從起點開始一步一步的做排除法效率太低了。應(yīng)該先通過自己的經(jīng)驗、擁有的部分信息先邏輯推理一下，縮小排查的范圍。哪怕你最終還是需要調(diào)試的話，先做這個事情也會讓后續(xù)的工作更高效一些。
第二點，利用工具。這里的“工具”不要簡單的理解成利用“調(diào)試工具”。正如上面提到的，找bug的本質(zhì)是一個排除法的過程，那么任何能夠幫你更高效的做排除法的工具都是可以利用的。比如，
- 從系統(tǒng)的「事件查看器」中獲取更多的環(huán)境信息。
- 利用windows平臺的windbg、lunix平臺的MAT之類的工具直接分析抓到的dump文件。
- 借助可視化工具更高效的發(fā)現(xiàn)問題，如FlameGraph等。
另外，如果能主動的告訴你哪里出現(xiàn)bug了，就更棒了。所以，我們可以搭建一套查看方便，信息同步及時的日志框架，以便讓有價值的信息第一時間呈現(xiàn)在你的面前。如果有高效的篩選功能就更好了。
很多日志框架Z哥沒用過，就不發(fā)表什么言論了，但是elasticsearch + logstash + kibana這套用起來還是很爽的，體系也比較成熟，部署起來也很簡單，大家可以嘗試一下。再配上ElastAlert或者Sentinl，可以把實時預(yù)警機(jī)制也包含了。
最后，每次的迭代規(guī)模盡可能的小。這個說起來容易，做起來難，因為這是由整個團(tuán)隊的文化來決定的。這個點的內(nèi)容完全可以單獨開一篇講，這里就簡要闡述下。
MVP（Minimum Viable Product）式的小步快跑，其實除了讓系統(tǒng)或者產(chǎn)品的功能演進(jìn)更科學(xué)之外，還可以讓每次迭代所面臨的風(fēng)險更小。正如前面提到的，你改一行代碼發(fā)布上去，如果出問題，你說問題在哪？
相對的，再想象一下，一次性發(fā)布一個開發(fā)了半年的版本，前一晚能睡的安穩(wěn)不？
總結(jié)
好了，我們總結(jié)一下。
這篇呢Z哥先闡述了我對“什么是bug”的理解，然后分析了bug是如何產(chǎn)生的，以及我們可能會做的一些慣性選擇。
最后給你的建議是，以如何更快的找到bug為出發(fā)點來考慮。通過「打好日志」、「學(xué)會利用工具」、「每次的迭代規(guī)模盡可能的小」這3種方式來進(jìn)行。
不過話說回來，雖然我們無法避免出bug（一個項目開發(fā)完后沒測出bug？你問任何一個技術(shù)人員都說“做夢呢”），但是爭取讓bug更少是我們的本職工作。
因為對bug容忍度低的另一層含義是，大家對系統(tǒng)的依賴越來越重，越來越多的事情在通過程序完成，而不是人力。
但是再有人咄咄逼人，就把這篇文章丟給他！有更多關(guān)于bug、IT培訓(xùn)等問題，歡迎私信咨詢。
