Photo by Arnold Francisca on Unsplash
最近一位非技術職同事問了我一個問題
「你在 Debug 的時候有SOP 嗎?」
嗯? 什麼SOP? 我從來沒有想過這個事情，Debug 能有SOP 嗎?
Debug 是解決程式錯誤的過程，最早的起源真的是因為一位名為 Hopper 女性程式設計師發在計算機上的一隻飛蛾，不過把飛蛾貼在工作日誌也是蠻有趣的，那張工作日誌現在成了博物館的展示品之一，當初一定沒有想到可能只是因為有趣才留下來的東西會變成博物館的收藏品。
Debug 有 SOP 嗎?
我個人認為沒有，雖然在程式的世界裡，都是非黑即白，不像人類一樣會有所謂的灰色地帶，但是很神奇的事，會很常遇到很相似的Bug，卻很少會有一模一樣的 Bug ，除非是沒有真的把Bug 解決的情況下才會一再發生一樣的Bug。
Debug 我覺得有幾個大原則，如果要把它們認為是SOP 感覺真的不像，所以我個人比較喜歡把它們當作是原則
就是
- 重現問題
- 大膽假設，小心求証
- 能解則解，無解則降低發生率或放棄
重現問題
看到任何Bug 的第一步，就是要重現問題，想盡辨法把問題重現出來，這時候若有好的QA 可以配合的話，就會輕鬆很多，因為QA 會協助重現問題，不過並不是每次都很幸運能遇到這麼好的QA (有遇到的話要心懷感激啊!!)。因為重現問題可以說是最難的部分，只要能不斷重現問題多數情況下都可以找到問題的解法，重現問題之所以難，是因為有很多時候都是要有特定的步驟、特定的OS 版本或是特定的環境(如：手機本身的情況)，所以解Bug 的時候，最~最~最重要的就是要重現問題，如果問題無法重現，基本上也可以說那個就不算是 Bug了。
大膽假設，小心求証
電腦科學也是一種科學，所以當然適用於科學常說的方法(?)，這個原則我覺得在軟體開發中是很重要的，不只是用在 Debug ，開發或是 Refactor 的時候都需要有這樣的思考與行動，解Bug 的時候有很多時候需要做點推理，假設是某個地方出了問題，然後去驗証這個假設，還要用各種方式去驗証，刻意把參數改成極限值或是設為不可能的數值，即使心中認為「怎麼可能會是這樣?」還是要去驗証，因為通常有80%的機率就是心中認為的「不可能」，然後下一秒就會忍不住想要大笑，也許不是每位Developer 在解Bug 的時候到後面都會忍不住想大笑，但我想應該大家或多或少都有幾次會想要大笑吧。
能解則解，無解則降低發生率或放棄
對於Bug 呢~如果能解決它是最好的，當然都會先以「解決它」去思考，去行動，遇到真的解不了的Bug 也不是沒有，畢竟有些Bug 真的是要天時地利人合的時候才會出現，最壞的方式就是放生它，但是放生之前，一定要找到問題的原因，無論是什麼原因，一定要找到它，再來就是要看有多少使用者被影響? 都是使用哪一版 OS 的使用者? 是用那種機型的使用者? 未來是否有要調整與這個Bug 相關的功能? 等等，要先看過很多東西之後，才能決定是否要放生它，所以不能隨便就放生的。
另一個是看能不能想辨法降低發生率，有些可能疑於技術債的關係或是時間壓力，不能做大幅度的修改，能盡可能降低發生率的話就很好了，例如：讓這個問題不容易被使用者觸發，在 UI 上限制使用者的操作、補上參數檢查機制，讓某些極限值、空值或是 Null 不要出現在之後的處理中等等，雖然並不一定會完全讓這個 Bug 消失，但至少讓受影響的使用者變少，就某種層面來說也算是解決Bug 了，當然你知道它並沒有解決。
每一個Bug 都獨立的個體，即使相似但絕對不會一樣，每一位Developer 都會有自己的Debug 的方式，經驗也不同，有些人可以很快就看出 Bug ，也有些人需要花點時間，不過呢…如果要讓 Debug 順利的話，還有一個很重要的事情，就是
開發階段就應該要好好思考過
盡可能想到目前能想到的最好方式
過去我的主管告訴我，寫程式一定要先思考過，拿紙筆出來畫流程、畫 UI 、寫下邏輯，多看幾次，盡可能寫出你能寫出的最好方式，要記住寫程式最花時間的地方不是在「寫」而是在「想」
雖然寫程式也算是一種技術，很多時候比起理論直接動手寫能更快學習到，但不要忘記只模仿是不行的，要去理解與思考這位Developer 為什麼要這麼寫，盡所能去理解再運用。
如果在開發階段就能好好思考過，無論是流程、UI 架構都思考過，未來在維護或Debug 上都會有很大的幫助!
最後祝Coding 愉快~
