不要用憶測的方式來除錯

Sep. 22 12:47~13:34

 

《The Pragmatic Programmer》是10幾年前讀過的一本舊書，書中的兩個觀念「Rather than construction, programming is more like gardening」與「All programming is maintenance programming」在當時改變了Teddy對於軟體開發的看法。今天談書中提到的一個小技巧：「Don’t Assume It—Prove It」。

***

以前還在當工程師的時候，經常有機會和同事一起除錯。由於待除錯的程式碼當初主要是由同事主寫，Teddy並不清楚程式的運作細節，因此在合作除錯的過程中，會一直問一些「蠢問題」。

Teddy：這個method是做什麼用的？

同事：它是用來設定某個排程工作。

Teddy：你怎麼知道這個設定有正確執行？

同事：（不耐煩的語氣）程式都跑起來了，排程工作的檢查結果也顯示在畫面上，這樣還不算正確執行嗎？

Teddy：我知道整個流程串起來「看起來」是可以動的，但如果我們無法確定這個流程裡面的每個單元都是正確的，就很難找出bug。

同事：這樣太花時間了啦，這個method我確定它是對的，問題應該是出在別的地方。

Teddy：你怎麼確定它是對的，你有幫這個method寫單元測試嗎？

同事：這個method相依的物件太多，很難寫單元測試。但我有手動測試確定它是OK的。

Teddy：我們要不要利用除錯的機會，順便幫它補寫單元測試，來確定這個method真的沒有問題？

同事：我就跟你說問題不在這裡，不需要浪費時間做這種無意義的事情啦，先把bug找出來再說。

***

有時候Teddy會說服同事，由下而上用補寫單元測試的方式來除錯。有時候會先依據同事的直覺，從最有嫌疑的物件或method開始著手除錯。但無論如何，最後都儘量用撰寫自動化測試來證明「嫌疑犯」是清白或是有罪。

只要是人都有盲點，用憶測的方式來決定程式的正確性，是很不可靠的方法。當你說出：「這個地方應該不會有問題」的時候，請想想看有沒有相對應的各種測試案例（單元測試、整合測試、或是end-to-end測試）來證明你的憶測。這種心態剛開始會讓別人覺得你是一個「很龜毛」的人，但Teddy認為這是成為專業開發人員的一種訓練。龜毛就龜毛吧 XD。

***

友藏內心獨白：假設常常並不可靠。