筆者是一個老碼農，早已年逾 40，目前仍然奮戰(zhàn)在一線寫代碼、修 bug，并沒有出現(xiàn)傳說中的 35 歲危機。工作這么多年，方方面面的 bug 也接觸了不少，想作為一個老碼農分享關于修 bug 的心態(tài)問題。

首先作為一個程序員，只要是寫代碼，肯定是會產生 bug，除非這個人不寫代碼。所以，這一個基本的常識我們得心平氣和的接受。要是有個人吹牛說自己寫的代碼沒 bug，那一定是個騙子或者自大狂。但是這并不等于 bug 越多，就越牛逼，我們在編程的時候，肯定是要采取各種手段避免 bug 的發(fā)生。比如尤其要注意：

1、多線程、多進程并發(fā)訪問風險；

2、邊界條件處理；

3、遺漏的分支處理等防御性編程的基本思想。

在修復 bug 過程中，最重要的一個心態(tài)就是要切莫急躁，急躁是修復不了 bug 的。有的同學，領導進度催促的緊，他就東改一行，西改一行，企圖碰運氣把這個 bug 修掉。筆者工作這么多年，基本從來沒碰到過這樣的運氣。

代碼是這個世界最符合邏輯的東西，反邏輯的運氣是不會出現(xiàn)的。越是難修的 bug，越是進度緊張的 bug，越是要心態(tài)平靜。反復復盤代碼邏輯，復盤自身的模塊與其他模塊的關系，復盤全局的多線程數(shù)據(jù)訪問、時序邏輯。簡單來說，對自身關注的代碼以及你的代碼與其他代碼的邏輯關系梳理地越清楚，修復這個 bug 越成為可能。所以實在沒思路了，怎么辦？復盤邏輯！繼續(xù)沒思路了，怎么辦？復盤邏輯。

我印象比較深刻的，之前在修復 wayland 的 client UI 和 server weston 之間通信的邏輯時，crash 的是 Qt App，但是實際的問題是出在 weston 和 app 之間通信的 wayland message 時序上，這個時候唯一的辦法，就是理清 wayland 的協(xié)議，什么時候 client 和 server 應該發(fā)什么樣的消息，什么樣的消息導致窗口的 destroy 等，只能靜下來來，反復分析。一條條看捕獲的 client 和 server 之間的 wayland socket 消息，對照協(xié)議分析 client 和 server 進程之間的時序是否紊亂了。沒有其他的辦法。

退一萬步講，哪怕一個人真地瞎試把 bug 僥幸“修復”了，對個人的成長又有什么幫助呢?我們提煉了什么規(guī)律呢？理清了什么邏輯呢？自己能說的清楚為啥修復了嗎？這樣的蠻干是不會成長的。

在修復 bug 的過程中，不妨嘗試 refresh 一下自己的大腦。有時候腦袋麻了，思路就會短路了。不如出去呼吸五分鐘新鮮空氣，看似浪費了五分鐘，實則很可能在這五分鐘里面，獲得了一個思路。我個人經常碰到的情況是，在電腦面前坐麻了，心情也比較焦急，因為急著修 bug 啊。但是，娃放學到點了，我不得不出去接個娃，十來分鐘路上，我發(fā)現(xiàn)這個 bug 我回來就可以修復了。所以，有時候，慢就是快?？此评速M了十分鐘接娃，實則這十分鐘的新鮮空氣清醒了大腦，所以修復這個 bug 的貢獻可能得算到娃的頭上。

寫代碼的時候，不妨多加一些斷言/BUG_ON 之類，在不確定的位置，留下一下打印。代碼的世界充滿了神奇，你覺得走到某個位置的時候，a 必然是等于 1 了，但是代碼跑起來偏偏就等于 2。為啥呢？因為是代碼就有 bug 啊，是 bug讓它不等于 1 的。那么我們可以嘗試加一個 BUG_ON（a!=1）。任何的 bug，都是出現(xiàn)地位置越早，越好修的。BUG 遵循“早死早超生”的規(guī)律，如果你在 a 處犯錯了，死在了 b 處、c 處、d 處，顯然你比較難追溯到 a 處，但是如果你在 a 處就提前偵測到了潛在的問題，則主動降低了修復這個 bug 的難度。尤其是產品上線后，甚至會出現(xiàn)實驗室反復測試都無法復現(xiàn)的 bug，這些異常點增加的 BUG_ON、打印之類，都可以幫忙提示修復的方向。

修復 bug，需要建立業(yè)務領域知識的廣度和深度。作為一個 Linux 內核工程師，比如改了內存管理、page fault、swap 等的代碼，看似僅改了一個模塊的很少一部分代碼，但是由于這個代碼太底層，它可能和很多其他的內核組件比如調度、文件系統(tǒng)、VFS、page cache 等都有千絲萬縷的聯(lián)系，這個時候，沒有對內核的廣度和深度的理解，是很難修復 bug 的。所以，我們千萬不要小看了修復 bug 這個事情本身，同樣的 bug 有的人弄一個月都不知所措，有的人兩天就解決了。你覺得差的這 28 天原因是啥？無他，懂還是不懂業(yè)務知識，而不是編程語言本身。

所以，對 C、C++、Java 等語言的掌握度是絕對拉不開程序員距離的，能拉開程序員距離的是對編程語言施加的業(yè)務的掌握度。語言是個最基本的東西，你比如每個美國人都會說英語，但是每個美國人的業(yè)務水平都不一樣，有人 0 元購，有人喬布斯。作為一個程序員，你能拿出來炫耀說自己 C 語言爐火純青嗎？這個沒用的，就跟一個美國人說自己英語說的好一個道理，沒意義。