大家好，我是Z哥。

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

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

我想上面的言語幾乎每個程序員都聽到過。特別是面對那些“稍懂技術”的同事的時候。

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

很多人之所以會產生前面提到的這種誤區，是因為他們潛意識里將工作量與代碼量掛鉤了。

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

我們程序員當然清楚，事情并不是這樣。不管是實現一個新功能還是修復一個線上 bug ，我們都不可能直接上手 coding，因為我們不知道代碼應該寫在哪，怎么寫。

/01? 實際修 bug 的過程是怎樣的/

就以修復 bug 為例，常規的處理流程是這樣的。

確定 bug 相關的環境信息。

梳理 bug 所在的整條業務鏈路。

分析 bug 在鏈路中的哪個環節產生。

調整代碼，修復問題。

其中的每一個環節都存在著增加時間的因素，我們來一個個展開。

/02? 每個環節影響時長的因素/

01? 確定 bug 相關的環境信息

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

這會導致程序員排查 bug 的時候，方向就錯了，被誤導了。一旦方向錯了，不管花再多時間，都是白白浪費掉的。

雖然說一線的業務人員，不懂技術是常態，但是不可否認的是，這的確會對修復 bug 的時間產生很大影響。

02? 梳理 bug 所在的整條業務鏈路

如果恰好這條業務鏈路我很熟悉，甚至是實現業務邏輯的代碼都是我寫的。那么這里花費的時間就少得多。但是如果不是的話，我還需要花時間去梳理業務，然后找到業務對應的代碼在哪些地方，它們之間是如何組成、協調的。

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

03? 分析 bug 在鏈路中的哪個環節產生

大多數人應該都聽過斯坦門茨在福特生產線上畫一條線收了 1 萬美元的故事。他給福特開出的收據是：畫線 1 美元，知道畫在哪 9999 美元。

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

而且很多時候，一個 bug 所表現出來的現象與問題根源并沒有直接關系。

比如，提交訂單提示庫存不足。其實并不是庫存不足，而是請求庫存 api 出現了異常，甚至是由于下游的庫存 api 內部異常導致。這種層層依賴隨著業務鏈路的延伸會變得更加復雜，這自然需要大量的時間去抽絲剝繭。

還有更夸張的情況是，完全沒有關系。比如，提示 XXX 失敗，實際卻是 YYY 的問題，因為這個提示語句是從其他代碼里 copy 過來的……（有遇到過這種情況的來評論區確認過眼神一下）

04? 調整代碼，修復問題

條條大路通羅馬，一個問題往往也有很多種解決方案。修復得快不代表修復得好，找到最簡單、最優雅的解決方案是需要經過思考的。

哪怕是看似在確定的地方去修改代碼，如果你運氣不好，碰巧要修改的 function 對外有 100 多個引用，而且你還需要改動傳入的參數……

此時，你得祈禱不會遇到那種牽一發而動全身情況，細品一下下面這張圖你就懂了。

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

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

05? 修復完后

作為有責任心的程序員，并且出于對自己的口碑負責，肯定不會將結果的驗證完全交由測試人員來做。

所以，自己還得多花一些時間來驗證，自認為容易出現問題的場景下是否還會出現問題。這，也需要時間。

/03? 提高修復bug效率的方法/

當然，上面這些理由也不是我們懶于提高修復 bug 效率的借口，對于如何更高效地 Debug ，包括應對生產環境的 bug ，可以看看我之前的老文。

《系統壞了，慌不慌》

《如何提高Debug效率》

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

《聊聊單元測試》

好了，總結一下。

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

因為在以下 4 個環節都存在著額外花費時間的事情。

確定 bug 相關的環境信息。

梳理 bug 所在的整條業務鏈路。

分析 bug 在鏈路中的哪個環節產生。

調整代碼，修復問題。

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

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

推薦閱讀：

• 我是如何保持長期寫作的

• 被同事嘲笑說技術方案沒深度？
  

原創不易，如果你覺得這篇文章還不錯，就「點贊」或者「在看」一下吧，鼓勵我的創作 ：）

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

如果你有關于軟件架構、分布式系統、產品、運營的困惑

可以試試點擊「閱讀原文」

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。