l

2015年9月28日 星期一

不要用憶測的方式來除錯

Sep. 22 12:47~13:34

螢幕截圖 2015-09-22 13.31.24

 

《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。

***

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

3 則留言:

  1. 我想,你同事應該是在查bug時,你又在旁邊碎碎念有沒有做單元測試,有沒有辦法證明method是否ok等等的, 他已經查bug查的很煩了,自然心情不好,口氣也不好...以我的經驗,程式多做log對於bug查察會比較有幫助,問題發生後問能不能做單元測試應該都太晚了...

    回覆刪除
    回覆
    1. Bug一小時內要解掉,寫單元測是很難來的及,先急就章沒啥不對

      刪除
  2. 專業跟不專業之間的差別就在這邊,各行各業都有類似的標準,但共同點就是都會被說成龜毛 XD

    回覆刪除