In 91

孟哲 Facebook 原文內容（經過排版與標示）

上個週末參加了 91 哥開的 TDD 與重構課程，兩天課程體會蠻多的，除了更全面地了解 TDD 的精神、怎麼使用、跟持續重構的搭配、親身體驗 TDD 會遇到的挫折以及如何避免/突破，也深深覺得 TDD 實在是個富含生活哲學意味的開發模式，各種要點似乎都能和生活觀緊緊相扣。以下整理一點個人心得紀錄，文長慎入。

話說這課程蠻神奇的，一張投影片都沒有，除去開場講師用母雞帶小雞的步調詳細解說需求探索的部分，大部分時間都是同學們照著講師提出的需求，在現場被抵在脖子上的時限逼著實作，很有一般專案開發的臨場感吧。由於對 TDD 模式不熟悉，在有緊迫時間壓力的情境，很容易就讓人忍不住跳回傳統開發思維的舒適圈，於是就容易寫出一堆高耦合的糞 code。不過糞 code 倒也不是毫無用處的，它們在之後都變成了練習重構的肥料。

此外，兩兩 pair 進行的 coding 模式，也考驗兩人的溝通能力，記得我在第一 round 實作開始沒多久，馬上就被 91 哥從背後拍拍肩膀糾正：「不要放棄溝通啊。」

的確，我的確很容易放棄溝通，在發生雞同鴨講或是彼此頻率沒對上的對話時，假如對方不是熟到爛掉的親友，我總在第一時間會退一步，說好聽點是想要觀察對方想說/想做什麼，但說穿了就是懶得花心力取得共識。在開發的情境中，能及早取得共識是一件極重要的事，哪怕第一時間需要多花點口舌釐清兩人的想法，也比後面走了岔路再回到原點依然要花費口舌重新釐清來得划算。這一點其實也和 TDD 的精神不謀而合，對於錯誤及早發現及早治療，沒弄清需求就往下走，無異於賭博。很高興這一點能被戳破，讓自己有一個改善的契機。

至於要怎麼確認對方認知和自己認知是否確實一致？ 91 哥也傳授了一個意外簡單的方法：

把自己認知的邏輯代入具體數字的表述給對方聽，如果認知是錯誤的，就可以得到即時的糾正，要是明明認知錯誤對方卻沒有即時糾正，那認知錯誤所導致的結果就是兩人一起承擔，不會有責任都在某一方身上的問題，不得不說真的是人性化！很像用爛提案逼出好點子的麥當勞理論，也有 Specification By Example 的味道，「怕犯錯或怕問錯」則是這簡單方法最大的門檻，所謂「要臉就學不會」就是這麼回事吧。

91 哥霸氣的宣言可以精準地描述 TDD 精神中個人最喜歡的一部分：

大概類似這樣的句子，有需求才有動作，需求不用很大很遠，但要清楚並且有效益。而凡事過猶不及，如果一直坐在原地等所有需求或計劃都出來了才動手，又不符合 TDD 精神了。TDD 的啟發是走出第一步，後面的路才能繼續走下去，計畫永遠趕不上變化，掌握大方向以後就可以開始前進，細節是依著沿途的需求來慢慢完成的，人生和專案啟動以後永遠都是隨時在變動的渾沌狀態，一個能死守的完美制度或計畫只能是妄想，“Plans are nothing. Planning is everything.”

回到技術的部份，單元測試是 TDD 循環中最基礎也最重要的一個環節，沒有它做為基底，說要重構什麼的都是假的。單元測試是盾、重構是劍，也不是沒有不帶護具就上戰場的人，但如果這人不是身經百戰的老兵，我們就會覺得應該是梁靜茹給了他勇氣。

當初報名課程之後覺得自己好像有點衝動，竟然就這樣花了萬把塊跑去台北上才短短兩天的課，上課內容還是我才認識不久甚至在實務上都沒使用過的 TDD。但一方面是當下真的想把這開發模式納為己用，另一方面則是對 91 哥的課程蠻有信心的，畢竟也是大前輩而且看課程口碑都不錯，所以也就還是衝了，這對於一個失業人士來說還真算是一筆不小的投資啊，但反正我是「錢沒有不見只是變成你喜歡的樣子」思想派的，哈哈。

上過極度燒腦的兩天課後是真的覺得獲益良多，當然距離能活用還要經過反覆不斷的練習（91 名言：「不練習，都是屁。」） 這是一條漫漫長路，但至少是方向明確的漫漫長路。

以前都覺得資訊流通的時代獲取知識應該不再需要花什麼錢了，這個想法在近來才漸漸被自己推翻。前陣子上 Hahow 的前端特效課程時清楚地感受到，沒有專家在前指引，在現在知識量爆炸的環境下自行摸索一門全新領域的知識所要花費的時間簡直是以倍數計算，更危險的是自己摸索的過程，有可能根本就「不知道自己不知道什麼 」（You Don't Know What You Don't Know），所以我覺得完全自學而成為專家的人，真的很強。

這次的 TDD 課程再次有這種感覺，由網路上片面資訊所建立的 TDD 認知跟實際上的 TDD 之間便已經有一段差距了，如果沒有實際走過一遭挫折到突破的路，永遠不會對這模式有信心，自然也不太可能在實務上咬牙決定使用結果遇到問題時想盡辦法克服，信心真的太重要了啊。

91 哥說他的課很難留下一些實體教材這類 KPI 性質的東西，但課程帶來的影響其實是直接種在學員們心裡了吧。轉職中的無業遊民也沒法推薦同事去上課什麼的，僅以此文幫 91 哥的課程做個口碑推薦。

軟體業朋友如果有興趣想要體驗一下懷疑自己「是不是不會寫程式」的感覺，可以看看他開的課程和一些之前課程花絮照片之類的，因為名額不多通常都蠻快就額滿了，大概都要提前半年報名。最後感謝雅令老ㄙ優秀的前同事兼學弟推了我一把讓我下定決心去上課，感恩感恩。

91 的補充

我從 2018 年開始的技術培訓課程，就捨棄不用投影片來上課，而是想辦法讓上課的主題、挑戰、學習都更貼近真實世界的實務開發。也可以依據現場情況，來對上課內容做最好的調整。

而這門課更是把這精神推到極致，連重構的素材都不是事先準備好的，而是讓每一組在時程壓力內想辦法完成需求的過程中，所產生出來的 legacy code，並經過一起 code review 來檢視每一組產品代碼設計上的壞味道，最終讓大家推一組最髒的代碼，在上課時當場重構給所有學員看。

在實際的產品、專案開發過程中，我們不就是被時程壓力逼得總寫出一堆又肥又醜又臭的 legacy code 嗎？而且因為實在太髒了，所以大家要嘛疊床架屋，避免修改到原本的代碼，讓歪掉的樓更歪，更容易垮。要嘛宣佈病人沒救，重構不了只能重寫。

更趁此機會讓大家了解到，重構不是只有 rename、extract method、extract interface 這麼單純的動作而已。如何辨識出壞味道，這些 code smell 會有什麼不好的影響，我們該怎麼基於 legacy code 上來重構，以消除這些 code smell，避免產品開始腐爛。

最後，同樣的需求如果透過 TDD，從一開始需求分析、測試案例探索的過程就截然不同。如何小步快跑，精準、不帶一絲浪費的滿足一個個從頭走到尾的 scenario，如何持續且即時地重構，來讓整體開發速度大幅提昇，並一路保持著「簡單設計」。

雖然沒有投影片，所有的步驟、過程、提示與解說，都在 GitHub 的 commit history 中，讓學員除了在上課中可以練習以外，回去還可以從任何一個時間點、步驟開始練習重構與 TDD 的套路。

TDD 不只是 test-first，用對方式也不會見樹不見林，測試「驅動」開發，該怎麼用測試來讓開發更加事半功倍，在這門培訓中就可以窺探一二。

參考

1. 【演化式設計：測試驅動開發與持續重構】
2. 【201811 第四梯次 TDD 與持續重構】學員反饋與心得
3. 【201902 第五梯次 TDD 與持續重構】學員反饋與心得
4. Facebook 粉絲專頁：91 敏捷開發之路

---

blog 與課程更新內容，請前往新站位置：http://tdd.best/