Debug 是門藝術

• 2019 年 12 月 31 日
• 筆記

【這是一猿小講的第 78 篇原創分享】

最近想結合發生在身邊碼農身上的一些小故事，嘗試表達一個觀點「Coding 是門技術，Debug 是門藝術」。

上期的分享《Coding 是門技術》主要通過引入身邊 Code farmer 擼碼的一些真實故事，掰扯了一下開發規範以及重構可以改變程式碼的設計的理念，並且文末我又嘗試總結了，人人皆知的一個看似專業而又非專業的擼碼套路（一篇流水賬，而卻忘了升華，我就喜歡這麼自嘲）。

但是，作為碼農，擼碼肯定是日常必須，畢竟要靠擼碼吃飯，但是為了能更好的保住飯碗，Debug 則顯得尤為重要，因為魯迅先生說過「程式猿 20% 的時間在 Coding，80% 的時間在 Debug」魯迅先生又說「他從來沒說過」。

好了，話不多說，請扶穩坐好，我們正式來聊聊 Debug 這門玄幻的藝術。

01. Debug 的精髓

Debug 的藝術，我簡單歸納為 「Debug 三步曲」。

第一步：FindBug。

無論遇到任何問題，Debug 時一定要清晰牢記，通過剝絲抽繭的方式，努力逐步縮小範圍，最終鎖定 Bug 的藏身之處。

第二步：FixBug。

依據擼碼經驗，經過多輪的修復-驗證-修復-驗證，最終讓Bug扼殺於無形之中。

（圖片來源於網路侵之刪之）

第三步：RecordBug。

為了保證 Bug 不二過，當然一定要把 Bug 的原因、現象、解決方式記錄在案，這樣就以防其他老鐵再入坑。

好了，接下來就一起看看，發生在身邊高雞攻城獅身上的一些有趣的 Debug。

02. Debug 的故事

故事一：運維小哥配置的 crontab 引發的 DeBug。

經常擼碼的老鐵都清楚，系統一般白天瘋狂吸引客戶，也就是瘋狂吸金，晚上一般會啟動 N 多個批處理，在運維小哥那兒也不例外，配置很多釋放資源、機器巡檢等一系列的 crontab 任務。

近期團隊讓運維小哥幫忙搞了一台新機器，上面部署了新服務，並且配置了一個每天凌晨 1 點 10 分定時執行清洗數據的任務。

10 1 * * * /app/clear.sh >> /app/log/clear.log

理想很豐滿，現實卻很骨感。每天凌晨 1 點定時任務卻遲遲未執行，於是就開啟了 Debug 的過程。

Step 01：FindBug。

核心原則「努力縮小 Bug 範圍」。

• 首先排除常規性的配置錯誤，例如目錄、腳本名稱配置錯誤；
• 然後排除腳本是否有執行許可權，通過 ls 命令，發現腳本執行許可權正常，而且手動執行腳本也沒毛病；
• 接著重新調整 crontab 的執行時間，確認是否會執行，發現確實到點了不執行，不過卻有一個很詭異的一個現象，那就是有一個每兩分鐘執行一次的測試腳本 test.sh 卻能夠正常執行；
• 大膽猜測，由於每兩分鐘的任務正常執行，有小時配置的任務卻不執行，此時不得不懷疑是機器的時間導致的？！運維小哥堅信時區沒問題，因為近期剛調整過，但是處於 Debug 環節，還是需要通過命令再次確認時區資訊。

如上圖示意，發現時區配置確實沒啥毛病。那哪裡會出現問題呢？會不會是 crontab 服務啟動的時候，時間還沒有調整呢，導致 crontab 的時間與當前的時間不一致？

眼尖的同學，此時會發現，時區配置的確晚於 crond 啟動時間。

Step 02：FixBug。

核心原則「扼殺 Bug 於無形」。

由於時區配置，但是沒有重啟 crontab 服務導致，那就重啟 crond 服務唄，重啟完，時間確實對了，效果如下。

修改完成之後，經測試完全 OK。目前再去看線上清理的批處理，一切跑的又是那麼的完美。

Step 03：RecordBug。

核心原則「每一個 Bug 都載入史冊」。

故事二：攻城獅玄幻的 rz 命令上傳的奇葩 DeBug。

不知道大家平時喜歡用什麼登錄線上伺服器，身邊攻城獅用的最多的莫過於 SecureCRT，用這款工具日常連伺服器、查日誌不再話下，不過用的偏多的就是用 rz 命令、sz 命令。

假如要向伺服器上傳文件，用 rz 命令就可以輕鬆搞定；假如要下載文件，用 sz 命令也可以輕鬆搞定（沒用過的老鐵建議嘗試一下，絕對會讓你 WOW！）。

不過最近身邊攻城獅光頭強，倒是在用 rz 命令上傳文件時，栽了個大跟頭，先拋個情景對話，讓我們感受一下光頭強那種百思不得解的痛苦。

眼尖的同學會發現主要問題，在光頭強同學輸入 rz 命令後，總是提示如下資訊。

rz waiting to receive. Starting zmodem transfer.  Press Ctrl+C to cancel.

然後就沒有然後啦，汗顏。正常情況下輸入完命令，會提示上傳文件窗口，然後選擇要上傳的文件，就應該上傳成功了。

何解？面對工具性的 Bug，無需花太多時間在 FindBug 上，直接可以跳到 FixBug 環節，建議直接卸掉重裝就好了，但是令人匪夷所思的是重裝了還是不好使啊，而且光頭強還沒有其它 ftp 上傳工具。

此時腦海中應該彌補一個場景：緊急部署線上應用，但是就你一個人有登錄堡壘機的許可權，而你又無法進行上傳文件，那麼此情此景，只能用下面這張圖來形容。

面對這種比較玄幻的問題，只能另闢蹊徑，建議光頭強老弟直接拖住上傳的文件到 SecureCRT，未成想確實好使！

面對這種玄幻的奇葩問題，也只能奇葩對待啦。

03. Debug 的武器

武器推薦系列一：用 Debug 來發現「什麼是別人家的程式碼？」

為什麼別人家的程式碼，不但寫的好，而且Bug 少，最重要的是從來沒因為 Bug 扣過績效，莫非有什麼奇招。

擼碼久了就知道了，Coding 是門技術，但是擼碼也是有套路的，很多攻城獅在擼碼完成之後，喜歡採用 FindBugs 工具插件，找找有沒有潛在的程式碼風險。

不過也有很多老鐵，擼碼完成之後，喜歡用 sonarQube 來提升提升程式碼的逼格，隨便貼一效果圖。

上期分享我們提到了《阿里巴巴Java開發手冊 v666.pdf》，其實也有一款把阿里巴巴 Java 開發手冊中的規約的插件，可以在你擼碼的時候，自動幫你檢測是否符合規範（So，牛掰），該插件已經在 Github 上開源。

https://github.com/alibaba/p3c

以上幾款讓 Bug 扼殺在搖籃里的武器，感興趣的老鐵，可以親自體驗一下。

武器推薦系列二：線上甩鍋的 DeBug。

久入職場，遲早會經歷各種奇葩的鍋。鍋該背的背，不該的背堅決不背，要有自己的態度。但是面對不該你背的大黑鍋，如果你卻拿不出證據，只能啞巴吃黃連，有苦也說不出。

例如你剛上線了應用，伺服器 cpu 或者記憶體就瘋狂報警，此時微信群里直接把鍋扣你頭上，你該怎麼應對？

那肯定是沉著冷靜，並按照之前的一篇分享《這部技術葵花寶典真的很硬核》逐步去排查解決。

另外面對線上重要模組卻沒有任何日誌輸出，排查無從下手的情形時，不妨在關鍵位置列印日誌，以便儘快定位問題，快速止損。

04. Debug 的態度

有 Bug 不可怕，Debug 是我們前行的催化劑。

面對 Bug 要沉著冷靜，不要像生吞蜈蚣一樣，百爪撓心。

Debug 要剝絲抽繭，努力縮小範圍，找到 Bug 點；通過日常的經驗積累，解決 Bug 於無形之中；針對 Fix 的 Bug一定要載入史冊，因為它絕對是一筆財富。

再拋幾個玄幻的問題 Debug 場景，結束咱們的分享。

• 為什麼你一來我這兒就好了？剛剛怎麼調試都不行？！ 哎，Debug 是玄學藝術！
• 為什麼你這麼一操作就好了？剛剛我也是這麼操作的啊？！ 哎，Debug 是玄學藝術！
• 線上部署了 4 台服務，配置都一樣，項目 war 包也一樣，為什麼偏偏只有這一台有問題？幾經排查無解，而且換一台機器又恢復了平靜。 哎，Debug 是玄學藝術！