大家好，我是Z哥。

“這個(gè) bug 的問題不是很明顯嗎？怎么這么久才搞定？”

“就改一行代碼，你怎么弄了這么久？”

我想上面的言語(yǔ)幾乎每個(gè)程序員都聽到過。特別是面對(duì)那些“稍懂技術(shù)”的同事的時(shí)候。

我覺得這篇文章特別適合你收藏一下，為什么呢。首先，當(dāng)你再次遇到這種情況的時(shí)候，翻開這篇文章，可以幫助你降降火，讓你冷靜下來。其次，還能時(shí)不時(shí)地在朋友圈轉(zhuǎn)發(fā)給你的“稍懂技術(shù)”的同事看看，給他一些暗示，哈哈。

很多人之所以會(huì)產(chǎn)生前面提到的這種誤區(qū)，是因?yàn)樗麄儩撘庾R(shí)里將工作量與代碼量掛鉤了。

他們腦海里的程序員像電視電影的中的那些黑客那樣，palapala 地敲擊鍵盤，瘋狂地 coding，看上去都不帶思考的，然后軟件就寫成了。

我們程序員當(dāng)然清楚，事情并不是這樣。不管是實(shí)現(xiàn)一個(gè)新功能還是修復(fù)一個(gè)線上 bug ，我們都不可能直接上手 coding，因?yàn)槲覀儾恢来a應(yīng)該寫在哪，怎么寫。

/01? 實(shí)際修 bug 的過程是怎樣的/

就以修復(fù) bug 為例，常規(guī)的處理流程是這樣的。

確定 bug 相關(guān)的環(huán)境信息。

梳理 bug 所在的整條業(yè)務(wù)鏈路。

分析 bug 在鏈路中的哪個(gè)環(huán)節(jié)產(chǎn)生。

調(diào)整代碼，修復(fù)問題。

其中的每一個(gè)環(huán)節(jié)都存在著增加時(shí)間的因素，我們來一個(gè)個(gè)展開。

/02? 每個(gè)環(huán)節(jié)影響時(shí)長(zhǎng)的因素/

01? 確定 bug 相關(guān)的環(huán)境信息

在這個(gè)環(huán)節(jié)最常見的情況是，反饋 bug 的人員無法清楚地描述 bug 所處的環(huán)境，甚至是描述出現(xiàn)錯(cuò)誤（比如參雜了自己的主觀猜測(cè)，屏蔽了一些重要信息）。

這會(huì)導(dǎo)致程序員排查 bug 的時(shí)候，方向就錯(cuò)了，被誤導(dǎo)了。一旦方向錯(cuò)了，不管花再多時(shí)間，都是白白浪費(fèi)掉的。

雖然說一線的業(yè)務(wù)人員，不懂技術(shù)是常態(tài)，但是不可否認(rèn)的是，這的確會(huì)對(duì)修復(fù) bug 的時(shí)間產(chǎn)生很大影響。

02? 梳理 bug 所在的整條業(yè)務(wù)鏈路

如果恰好這條業(yè)務(wù)鏈路我很熟悉，甚至是實(shí)現(xiàn)業(yè)務(wù)邏輯的代碼都是我寫的。那么這里花費(fèi)的時(shí)間就少得多。但是如果不是的話，我還需要花時(shí)間去梳理業(yè)務(wù)，然后找到業(yè)務(wù)對(duì)應(yīng)的代碼在哪些地方，它們之間是如何組成、協(xié)調(diào)的。

這里可能存在的大坑是，這塊代碼不但我不熟悉，并且前人寫的代碼過于草率。此時(shí)，在幾百萬(wàn)、上千萬(wàn)行代碼的項(xiàng)目中，找到相關(guān)的幾千行代碼，并且捋清楚它們之間的關(guān)系，這可是個(gè)大工程，并不比把這個(gè)功能重新推翻重做容易。

03? 分析 bug 在鏈路中的哪個(gè)環(huán)節(jié)產(chǎn)生

大多數(shù)人應(yīng)該都聽過斯坦門茨在福特生產(chǎn)線上畫一條線收了 1 萬(wàn)美元的故事。他給福特開出的收據(jù)是：畫線 1 美元，知道畫在哪 9999 美元。

解決 bug 也是這樣過，分析 bug 產(chǎn)生的根本原因才是最困難的過程。

而且很多時(shí)候，一個(gè) bug 所表現(xiàn)出來的現(xiàn)象與問題根源并沒有直接關(guān)系。

比如，提交訂單提示庫(kù)存不足。其實(shí)并不是庫(kù)存不足，而是請(qǐng)求庫(kù)存 api 出現(xiàn)了異常，甚至是由于下游的庫(kù)存 api 內(nèi)部異常導(dǎo)致。這種層層依賴隨著業(yè)務(wù)鏈路的延伸會(huì)變得更加復(fù)雜，這自然需要大量的時(shí)間去抽絲剝繭。

還有更夸張的情況是，完全沒有關(guān)系。比如，提示 XXX 失敗，實(shí)際卻是 YYY 的問題，因?yàn)檫@個(gè)提示語(yǔ)句是從其他代碼里 copy 過來的……（有遇到過這種情況的來評(píng)論區(qū)確認(rèn)過眼神一下）

04? 調(diào)整代碼，修復(fù)問題

條條大路通羅馬，一個(gè)問題往往也有很多種解決方案。修復(fù)得快不代表修復(fù)得好，找到最簡(jiǎn)單、最優(yōu)雅的解決方案是需要經(jīng)過思考的。

哪怕是看似在確定的地方去修改代碼，如果你運(yùn)氣不好，碰巧要修改的 function 對(duì)外有 100 多個(gè)引用，而且你還需要改動(dòng)傳入的參數(shù)……

此時(shí)，你得祈禱不會(huì)遇到那種牽一發(fā)而動(dòng)全身情況，細(xì)品一下下面這張圖你就懂了。

就算運(yùn)氣不錯(cuò)，修改的地方很容易搞定，但是如果在這個(gè)過程中發(fā)現(xiàn)了一些寫得有問題的代碼，比如容錯(cuò)性差、性能差等情況。此時(shí)，作為有責(zé)任心的程序員，必須得出手去改掉啊。否則根據(jù)「墨菲定律」，后面還是得出問題，到時(shí)候如果自己還在負(fù)責(zé)這個(gè)項(xiàng)目的話，解決成本就更大了。

而且，有更多責(zé)任心的程序員，還會(huì)舉一反三，去將自己知道存在同類問題隱患的代碼都去改掉。這也需要更多的時(shí)間。

05? 修復(fù)完后

作為有責(zé)任心的程序員，并且出于對(duì)自己的口碑負(fù)責(zé)，肯定不會(huì)將結(jié)果的驗(yàn)證完全交由測(cè)試人員來做。

所以，自己還得多花一些時(shí)間來驗(yàn)證，自認(rèn)為容易出現(xiàn)問題的場(chǎng)景下是否還會(huì)出現(xiàn)問題。這，也需要時(shí)間。

/03? 提高修復(fù)bug效率的方法/

當(dāng)然，上面這些理由也不是我們懶于提高修復(fù) bug 效率的借口，對(duì)于如何更高效地 Debug ，包括應(yīng)對(duì)生產(chǎn)環(huán)境的 bug ，可以看看我之前的老文。

《系統(tǒng)壞了，慌不慌》

《如何提高Debug效率》

如果你想未雨綢繆，外加條件允許的話，建議把單元測(cè)試也做起來。

《聊聊單元測(cè)試》

好了，總結(jié)一下。

這篇呢，Z哥和你聊了為什么很多時(shí)候修復(fù) bug 沒有想象中的那么快。

因?yàn)樵谝韵?4 個(gè)環(huán)節(jié)都存在著額外花費(fèi)時(shí)間的事情。

確定 bug 相關(guān)的環(huán)境信息。

梳理 bug 所在的整條業(yè)務(wù)鏈路。

分析 bug 在鏈路中的哪個(gè)環(huán)節(jié)產(chǎn)生。

調(diào)整代碼，修復(fù)問題。

所以，如果以后誰(shuí)還說你為什么修 bug 那么慢，把這篇文章發(fā)給他。你說不出口的話，我替你說了。不過，后果自負(fù)哦～

其實(shí)大家都不喜歡修 bug ，特別是在低質(zhì)量的代碼中反復(fù)修復(fù)同一類型的 bug 。但是現(xiàn)實(shí)中，好像也有不少的人嘴上說著這樣，但自己卻總是在寫這些低質(zhì)量的代碼？歡迎分享你與 bug 之間的精彩故事給我～

推薦閱讀：

• 我是如何保持長(zhǎng)期寫作的

• 被同事嘲笑說技術(shù)方案沒深度？
  

原創(chuàng)不易，如果你覺得這篇文章還不錯(cuò)，就「點(diǎn)贊」或者「在看」一下吧，鼓勵(lì)我的創(chuàng)作 ：）

也可以分享我的公眾號(hào)名片給有需要的朋友們。

如果你有關(guān)于軟件架構(gòu)、分布式系統(tǒng)、產(chǎn)品、運(yùn)營(yíng)的困惑

可以試試點(diǎn)擊「閱讀原文」

總結(jié)

以上是生活随笔為你收集整理的这么简单的bug，你改了2天？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。