除錯的態度

July 26 20:51~22:00

連續寫了好幾天的跨界開發，好像快演變成本土劇那種拖戲的劇情，所以今天要換個主題，談一個除錯（debugging）的觀念。以前Teddy還在帶team的時候，經常有人會找Teddy一起幫忙除錯（pair debugging）。基本上合作除錯時Teddy會要求：

• 請對方說明一下錯誤訊息與錯誤現況，如果可以找出可讓此錯誤重複出現的操作模式更好。
• 請對方解釋一下可能出錯的程式邏輯，包含系統架構（模組與模組之間的互動關係）或是一起看一下某段程式碼的內容。
• 如果有測試案例，則跑一下這些測試案例，看看結果如何。
• 請對方猜測可能發生錯誤的原因。

接下來Teddy會以一個第三者的角度，用問答的方式來詢問對方問題，例如：

• 這個API這樣子使用對嗎？它的傳回值是什麼意思？如果是null會怎樣？
• 這個物件是由誰來負責初始化的？會不會根本就初始化失敗但是卻沒人發現？
• 如果網路斷線，這段程式可以立刻知道嗎？還是會卡在這個method上面？
• …（一直問下去，等到問不下去的時候通常bug也快找出來了）

這種除錯的方式看起來很簡單，沒錯，是很簡單，只要一直問問題就好了。但是，實際上問到後來經常會搞到問答的雙方火氣很大。為什麼？

***

被問者內心獨白：這個問題的答案明明就很明顯啊，用膝蓋想就知道這段程式是OK的，有什麼好問的？一直問一些無聊的問題，簡直在浪費我的時間啊。我這根本是「請鬼拿藥單」啊！

發問者內心獨白：這些程式又不是我寫的，你沒有辦法說服我這段程式真的沒問題，我又如何可以排除心中的疑問呢？話說回來，我是來幫忙除錯的耶，你還不合作一點，這樣我要怎麼幫忙？

***

在除錯的過程中，或者是廣義的來講，在寫程式的過程中，如果心中有任何疑惑，千萬不要用「猜的」，或是「抱持著在公堂之上大膽假設一下應該不犯法」的這種想法。因為，通常只要是鄉民們心中不確定而又想要偷懶打混的情況下所寫出來的程式，幾乎都會出錯。所以在《The Pragmatic Programmer》這本書中的第97頁，作者建議鄉民們在除錯的時候，要抱持著「Don’t Assume It---Prove It」。除錯的時候不要用「我認為…」，請證明給Teddy看。

鄉民甲：什麼，除個錯還要做證明題喔，那「拎杯（我）」不要寫程式了（摔滑鼠）。

謎之音：鼠在人在，鼠亡人亡XD。

這裡所說的證明不是用數學的方法來證明，最簡單的方法就是寫一隻單元測試程式，來確認自己的假設是對的就可以了。大體而言，就算鄉民們在開發軟體的時候有寫單元測試，但是，既然出現錯誤，而單元測試又全部通過，就代表這個錯誤沒有被現存的單元測試給找出來（這一句是廢話XD）。所以，翻成白話文的意思就是說，單元測試寫得不夠多。既然如此，就利用除錯的機會，順便 補血 補寫一下單元測試，這也是補寫測試最好的時間點。

為什麼除錯是補寫測試最好的時間點？因為，bug是一種很奇妙的東西。今天就算鄉民們寫了幾千、幾萬行的程式，你的老闆都覺得這是理所當然的，鄉民們也得不到任何的稱讚。但是，只要鄉民們解了一個bug，尤其是那種「看起來很棘手的bug」，在老闆的眼中，馬上變成大紅人。也由於bug具備某種神祕與不可測的性質，所以也很難預估需要多久的時間才修的好。所以，此時不藉機補寫測試更待何時。

***

嘴砲雖然厲害，但是光靠嘴砲是無法解bug滴。請用測試案例說服你的夥伴，不要用嘴砲打他XD。

***

友藏內心獨白：跨界系列再寫下去Teddy就要從人間界跨到靈界啦 。