Before
在上課之前, 其實前同事曾經在開發團隊中導入一些測試和TDD的概念. 大部分導入的原因不外乎是因為在開發的過程當中, 時常會遇到自己左腳踩右腳的改A壞B, 改A壞B, 改A壞B (以發生的頻率來看大概重複7次都不誇張), 或者是使用者回報的問題不曉得應該被歸類在有bug還是之前沒談到的需求等等的狀況. 工程師們的另一部分時間, 可能是要維護同事們寫的code, 包含解bug或者是基於前人的code繼續開發等等的情境, 也是會遇上一些沒有註解又不知道改了會不會壞了別的功能的尷尬處境(又是改A壞B), 在邊抱怨前人沒留下文件邊開發的時候, 即便有心維護, bug解好功能寫好後, 可能又要趕下一次要上版的班車, 於是自己也成為產出legacy code的伙伴之一.
關於測試的學習, 一開始覺得有點害怕. 過去對於物件的抽換和Design Pattern的使用還不是那麼樣的熟悉, 如果要把自己的code全部都變得可測, 勢必要和過去自己寫的code來一場大刀闊斧的對決. 想到就覺得不如敷個臉休息好了. 在我們的團隊, 從前一次的導入測試到現在, 其實並沒有非常確實的被執行, 測試的覆蓋率也不高.
不過出門前, 同行的伙伴們也都有志一同的希望可以把所學帶回去給團隊. 既然每個人上課前都會懷抱的期待, 和一些等待被解答的疑問...那就出門上課吧!
in Class
你要解決的是什麼問題
這是這三天的課程裡面, 最讓我最常反覆咀嚼的一句話. 也是每一堂課結束的時候, 回家翻翻講義問問自己的題目. 從第一天開始學習什麼是Unit Test、什麼是Unit Test的特性, 在第一個Lab使用Visual Studio產生出來的加法器測試碼一起開始實作. 從最小的一步, 去了解測試是怎麼一回事.
接下來的每一個Lab, 讓我們反覆的練習: 1如何適當的定義測試的範圍, 透過物件之間的關係封裝, 切斷和別人的依賴; 2要如何在測試前後把環境整理乾淨, 讓每個測試都能夠重複的執行; 透過1212反覆的練習, 漸漸地去了解為什麼Design Pattern會有這些樣貌. 透過這些步伐走出來的路, 也才不會歪到為了物件導向或為了設計而過度設計的窠臼裡. 其中最讓人覺得最實用的, 便是切分每個測試的大小之後, 利用像selenuim這樣的工具做Web testing, 接著在Web testing的保護之下一層層的重構, 最後讓每個物件都有自己獨立的職責, 就可以很清爽的使用各個物件以及對他們測試. 到了第三天, 我們甚至幫測試程式產生live document. 不管是對上對下的管理, 甚至是未來的我們要漸漸邁向的CI都會是很好的幫手.
After
課後的這一個禮拜, 回過頭來重新爬了一次講師的[30天快速上手TDD], 再從基本觀念看起, 發現腦中能夠建立的連結已經比第一天還要清楚很多. 也在寫程式碼的過程當中, 慢慢從手邊的code開始重構.
這三天學習到的東西很難去量化, 或者是說自己是否會因此而開發又更快了幾個百分點. 但也逐漸地發現自己, 基於測試能夠勇敢的去抽開較複雜的legacy code. 又甚至在跟同事codereview的時候, 能夠直接和他討論為什麼要寫這行code, 是不是因為要滿足什麼需求. 就像Joey在課堂上說的, 每行code都是為了一個需求而存在, 這樣的信念無形之中其實就已經內化成實際的行動, 能夠去和身邊的伙伴討論.
技術是可以透過實作慢慢磨練出來的, 課後Joey和Kevin, Demo也會在教學平台上回覆大家的問題其實又讓我們學到更多. 例如導入的這門學問, 其實又是另一項功課了.
如果我們將身邊的每個夥伴寫程式的狀況列入一個個實例化的案例需求, 觀察同事們寫code和開發的習慣, 看看他們遇到新開發的code或是解bug的時候會有什麼樣的反應和習慣仔細地記錄下來, 去詢問大家的需求, 不曉得能不能夠真的從每個人的角度將測試開發這樣的習慣慢慢地內化成團隊的開發習慣 :)
Refence
課程主辦單位 : skilltree
參考書 : [30天快速上手TDD]
2015-26y (2)
