這甘A賽減少 Relearning？

Oct. 12 23:00~ Oct. 13 00:18


M. Jwo (應該是先生) 對於 Teddy 胡說八道的『消除浪費 (3)：Relearning』有點建言：

M. Jwo ：自動化測試等無法減少 relearning 的時間才對。

Teddy：您說『這不是肯德基 自動化測試等無法減少 relearning 的時間才對』，可否說明原因？


M. Jwo ：自動化測試甚至TDD等不是減少relearning，而是減少未來bug的發生。因為測試對裡面的細節不會描述，不然重構就無法發生。如果說自動化測試想要減少relearning，不如寫code的時候命名好一點，讓看到程式碼就能知道寫什麼，讓程式碼就是文件，比起測試部份更好。問題是這些都要回去看程式。真的想要減少除了pair programming以外，比如google實行的變形的方式，必須由supervisor才能commit code這些方法我覺得更好，不但有技術傳承更達到code review的功能。

***

除了虛構的路人甲以外，終於有一個真正的路人對 Teddy 唬爛的內容看不過去了（也許早就有很多...XD），剛好利用這個機會寫一篇文章也好（快沒內容可寫）。

基本上 M. Jwo 的講法 Teddy 完全同意，『寫code的時候命名好一點』，『pair programming』都可以減少 relearning 時間（最後那點關於 google 的作法 Teddy 不了就不加評論）。

大部分的鄉民可能會認為『測試』就是為了『找 bugs』。知道 TDD 的人會說『TDD 是一種設計，不是測試』。不管自動化測試，TDD 的『原意』或是『主要目的』是什麼，Teddy 認為其結果（或是副作用？！）是可以達到減少 relearning 的效果。

想像一下，如果你寫了一個 method X，但是沒有為這個 method 寫 unit tests。一個月後，有人回報你的系統有一個 bug，你花了 5 個小時才找到，原來這個 bug 發生在 method X 中。你『重新學習（重新發現）』到這個 method X 的行為有問題。如果當時有利用自動化測試將這個 method 的『正常行為』記錄下來，而且有頻繁的執行這些自動化測試案例，那麼當問題發生時，便可立即發現（假設你的測試案例可以測出問題），減低『重新學習』的時間。

***

用白話文解釋，有一個人（小明），從小不學無術，到處做壞事，從 16 歲開始就不斷地進出監獄，卻一直沒有學會教訓。一直到小明 50 歲的時候，遇到一個義工，在這位義工不間斷的勸說與教導之下，小明最後終於改邪歸正。此時小明語重心長的說了一句：

小明：如果早點認識你（義工） 我的人生就不同了。

小明就好比是『一支沒有測試案例的程式』，發生了 bugs 卻渾然不知要如何改正，從何改正。即使是坐牢（程式當機）的時候有點苦悶，但是出獄（重新開機）之後又固態復發（期待下一次的當機？！）。


喋喋不休的義工，好比自動化測試案例，當行為偏差的時候可以立即示警，以便即時改正。想一想，小明花了幾十年的時間才學習/重新學習到正常的行為，這當然是一種浪費。

（Teddy 內心獨白：這個例子有點牽強...一時想不出更好的比方）

***

每一個自動化測試案例都紀錄著『程式正常行為的某個執行路徑』，從這個角度來看，逐一去執行測試案例便可逐一的了解程式的（片段）行為，可以跟 code reading 互相搭配服用。
 
依據 Michael C. Feathers 在 『Working Effectively with Legacy Code』的講法，『Legacy code is simply code without tests』。為什麼大家都怕維護別人的系統？因為別人做的東西無法了解啊，就算設計的再好（套用一堆偉大的 patterns），程式的名子取的再棒（Kent Back 附身），只要沒有測試案例，難保改一行產生 N 個 bugs。

換個角度來看，如果鄉民們交接到一個有完整測試案例的系統，你新增了一個功能，跑了全部的測試案例，發現沒有問題，於是你『大膽假設』你沒有把系統改壞。所以，如果你沒有時間，你就不需要去立即被迫去『學習』這個系統的程式碼（延遲決定）。也就是說你可以暫時完全排除 relearning 的需要，這樣應該也算是有給它『減少 relearning 時間』的啦。

結論

阿貶內心獨白：自動化測試有沒有減少 relearning 的時間...有那麼嚴重嗎？！趕快放我出來先。

***

友藏內心獨白：感謝 M. Jwo 激發 Teddy 另一個瞎掰靈感。