『Effective debugging』 軟體與系統除錯的66個具體作法 — 筆記 (1)

Photo by Sigmund on Unsplash

週末閒暇之餘，有空提前預約了在桃園圖書館提供的工具書，也就是

『Effective debugging』 軟體與系統除錯的66個具體作法

在近期工作 & 開發過程裡，有時感覺到開發直覺漸漸鈍化，缺少了一些思想上的刺激 & 不同的解決思路，反而會漸漸地陷入只有過去成功Debug經驗才是正確無誤的思想盲區. 因此, 在避免這種情況持續惡化的情況下，決定借本書閱讀來破壞過往debug的刻板印象 & 舊有習慣。希望藉由閱覽不同的debug技巧，來優化解決工作線上產品之複雜 & 未知問題.

章節1 — 高階策略 (High-level strategy)

Solution 1 — 透過問題紀錄系統處理所有問題

在使用此方法時，首先需要具備的條件為擁有問題追蹤系統 (issue-tracking system)來追蹤問題。不管是使用任何日常頻繁使用到的工具，例如: Github、GitLab、prompt message etc…，使用者們可傾向頻繁使用單一 or 擅長使用之追蹤系統，而避免選擇過多系統來複雜化問題。透過使用其系統，可幫助改善以下問題：

1. 查看錯誤紀錄
2. 確保歷史紀錄存在
3. 可依據問題優先順序 & 嚴重性來分類工作優先級
4. 評估錯誤 & 反映問題
5. 吸取經驗並反饋輸出

Solution 2 — 以精確關鍵字上網查詢問題線索

我們會碰到不曾碰過的技術問題或者是不熟悉的工具而產生的技術債等問題。這時，擅長使用網路搜尋引擎，並輸入精準debug問題，會更有效率地解決問題。

例如：Stackoverflow也算是工程師們踏入IT領域時，避免不了需要長期打交道的吃飯好夥伴。上面有許多資深工程師們，分享debug經驗或者是code運行不成功的問題解析。另外，除了Stackoverflow，chatGPT也可適時地給予具體建議 & 解決方案 (本人也是chatGPT愛用者之一)，有時蹦出來的解答 & 問題思路讓我驚訝許久外 (如果可以，希望能把這個工具帶到任何考場XD)，也可以讓我去省思之前做的哪些debug過程不夠有效從而改進。

Solution 3 — 確認滿足前後條件

在寫程式時，假設加減程式是透過3個步驟來成功執行：

1. 宣告變數 & 儲存變數
2. 使用變數來進行加減方法
3. 回傳加減後之結果

如果說執行上述程式碰到編譯錯誤時，可從最一開始宣告變數開始，第一步確認是否有把宣告變數順利地傳送至正確方法裡。再來，使用加減方法時，是否有如預期地正確執行成功。最後，確認加減回傳之資料類別結果是否正確。

Solution 4 — 從問題向上到錯誤或從程式開始向下到錯誤

假設程式當掉時，有時可從下向上進行錯誤識別 & debug。或者是難以識別原因，例如效能、安全性跟可靠性時，也可從下至上進行。

Solution 5 — 找出新舊系統間差異

可透過比較正常之系統 & 有問題的系統已找出失敗的相關原因。例如：MacOS系統上，Python有些依賴性安裝包是支援，而Windows不支援。那麽就可透過不同系統判斷出該原因為何。

另外，需考慮所有可能影響系統行為之因素：程式碼 (legacy code)、輸入 & 輸出 (I/O)、呼叫參數 (paramters)、環境變數 (environment variables)、服務與動態連結函式庫 (function)。

Solution 6 — 使用軟體除錯設施

有效使用內建除錯功能可幫助達成以下目標 & 產生正面結果：

1. 透過選擇性的執行，精準定位失敗測試案例
2. 引入額外紀錄
3. 提供報告 & 其他效能細節資訊

舉例來說，shell腳本語言裡有該相關除錯追蹤功能：

sh -x test_script.sh

假設test_script.sh裡面是在執行環境部署之步驟指令，那麼sh -x 就能夠逐一顯示命令步驟。

Solution 7 — 建構與執行環境多元化

如果碰到當機或者是應用程式不穩定之情況，可透過建構 & 執行環境多元化來協助除錯及偵測潛在問題。

1. 可安裝虛擬環境(Virtual Environment)來確認自己寫的code是否在相關環境裡面可否運行。
2. 透過租賃雲端主機 (Ex. AWS EC2) 來進行相關程式功能在其作業系統上。

Solution 8— 專注最重要的問題

工作一陣子之後，會發現說：

Debug解決完還是會繼續產生新的bugs & 優化工作不會有結束的那一天

如果說真的就如上述所說，一直解決不完的話，那麼到底要如何選擇取捨在有限的時間內解決bugs呢? 答案的話，每個人會有各自的見解 & 解決思路，而排序優先級順序在該解決作法上會是一個舉足輕重的重要角色。

比方以下情境，假設個人手頭或者是當前團隊碰到以下3個情境：

1. 新功能準備上線 (預計下禮拜五)
2. 線上產品資料庫炸掉 & 被後端Query過多次而導致資料庫無法讀存取 (影響到上千-萬之用戶權益)
3. 支援品牌上線資料庫EC2尚未進行遷移 & 可能產生營運成本增加 (影響到公司營運成本等)

那麼我可能就會排序上面3個優先級順序為: 2 -> 1 -> 3. 答案也比較顯而易見，如果第二個問題持續惡化，那麼公司就會減少十幾百萬之業務損失，那麼優先解決此問題，才能夠避免業務進帳之損失。關於2 & 3的情境，假設優先選擇第三情境來解決的話，的確可以提前降低長期未來的成本損失。只不過，可能需要面臨的機會成本就是下禮拜要準備上線的功能無法準時交付，並產生release delay之情況。嚴重一點，也許是比增加營運成本更為嚴重的喪失用戶對於產品新功能的信賴關係。所以，在分析排序優先級順序的同時，也可以去試想一下各個情境優先執行的後果是什麼來進行推測，來最大化提升開發過程的產品迭代 & 開發效益。