TDD 的困難之處

上一章說明了 TDD（Test-Driven Development，測試驅動開發）的基本操作與運作原理，也談了它能解決哪些問題。讀者也許會懷疑：既然 TDD 這麼棒，為什麼不是每個人都用？為什麼自己用起來反而卡卡的？

事實是，TDD 從來就不是一個完美無瑕的方法。要享受它的好處，是得付出一定代價的。本章來聊聊 TDD 在實戰上真正的門檻。

入門容易，活用很難#

作者認為，要入門 TDD 並不算難，只要嚴守紅燈（Red）、綠燈（Green）、重構（Refactor）的流程，不要急著跨太大步，通常不會出什麼亂子。但這套方法的難，正是難在「嚴守流程」這四個字，因為它對自我管理的要求非常高。

如果你實際操作過一段時間，搭配 Kent Beck 的 TDD 一書來讀，大概會發現要做到書裡那種出神入化並不容易，總覺得少了點什麼。要把 TDD 真正用得活，作者整理出以下幾項能力是必須的。

需求訪談能力#

TDD 強調的是「避免浪費」。我們花很多力氣減少程式碼的浪費，因為多打一行字就是多花時間。但如果回到源頭，連使用者的現況、困難與期待都搞不清楚，整天只會要對方「確認需求」、「訂好規格」，那就算寫得再快、再漂亮也解決不了問題，最後仍然要重做。所以避免浪費，必須從好的需求訪談開始。

建模能力#

了解使用者的問題後，下一步是把它「翻譯」給開發者聽。就算自己訪談自己開發，也省不了在腦中或紙上建立一個模型，描述使用者目前的 context 以及期待達成的新 context。這個模型是開發過程中重要的依據，必須隨時參考。否則一旦掉入細節，很容易忘了自己走到哪、走偏了路又造成浪費。如果中途發現模型要調整，那就調，但不能沒有。

很多人讀 Kent Beck 的書時都覺得他超強，沒有畫圖、沒有草稿，就這樣一步一步把東西做出來。但作者認為，他不可能對成品的樣貌完全沒有預期，這個預期可能很模糊，也可能跟最後的成品相差甚遠，但一定存在，否則程式碼很難往前走。

分析、提 Solution 與列測項的能力#

有了模型，下一步就是進行分析、提出 Solution，並決定這個 Solution「在什麼條件下，應該有什麼表現」。這對 TDD 特別關鍵，因為 TDD 是「測試驅動」開發，測項列得好不好直接影響後續的順暢度。能切得小、切得準、彼此獨立的測項，能讓 TDD 如虎添翼；反之就慘了。

安排先後次序的能力#

有了測項之後，先要決定誰是第一個。每個測項代表一個特性，雖然最終都得做完，但順序排得好，可以讓每一步都走得很小，更貼近 TDD 的精神。因此，安排測項先後順序，也是把 TDD 做好的重要環節。

維持抽象思考的能力#

商業邏輯是抽象的，coding 是細節的。開發者每天都在抽象與細節之間來回切換。切換久了，難免不自覺地偏離抽象，方向就走歪了。

抽象思考能力指的是：隨時清楚這一行程式碼是為了什麼而打的；換句話說，「15 秒前你決定要實現的邏輯，跟你現在正在打的這行 code，是不是同一件事」。一旦偏離，浪費就出現了。

測試與程式的能力#

有了 Solution 並決定先做哪一項後，就是把測試與程式實際寫出來。這是硬碰硬的事，沒辦法繞開。例如「查資料庫看是否有符合條件的學生，有就發通知，沒有就回 400 給前端」，從手放上鍵盤到打出一份 code，中間要停下來查幾次 StackOverflow？前置工作做得再好，「寫 code」這件事仍然避不掉，因此「碼農」的基本功還是很重要，它絕不能成為開發中的瓶頸。

順帶一提，AI 已經能幫忙寫 code 了，這不是危言聳聽，而是正在發生的事。

辨識壞味道的能力#

TDD 要我們「先讓它能編譯、再讓它正確、再讓它變好。」前兩項可以靠 IDE 與單元測試協助，但第三項目前還是得靠自己。

你是否遇過這種情況：主管指著一段程式問你「這裡有什麼 code smell？」，你卻完全愣住，覺得自己一直都是這樣寫的，從沒覺得有什麼問題。如果你常遇到這種情境，那就有了一個明確的改善目標：加強辨識壞味道的能力。

而且要趕快加強，否則幾乎無法進入下一個動作：重構。

重構能力#

能指認出 code smell，下一個挑戰就是重構本身。你知道這裡有 Data Clump，知道這裡違反了迪米特法則，可是要怎麼安全地改？沒有足夠的重構知識與肌肉，即使在 TDD 過程中察覺到不對勁，也沒辦法快速把它變好。所以好的 TDD，背後也要有好的重構能力撐著。

打字速度與工具的使用能力#

最後這項，是作者接觸過的開發者最容易忽略的：打字速度與 IDE 工具的熟練度。

你知道這裡要把方法抽成 Delegate，知道這裡要抽出一個 interface 並讓所有呼叫端改用它，但你要花多久才能完成？五分鐘肯定不能接受。在 TDD 的節奏裡，腦袋運轉得很快，而思考最怕被打斷。如果中斷你的是老闆的電話，那沒辦法；如果是自己慢吞吞的手指，那就太冤了。

三秒會太短，但十秒、三十秒應該夠了，再長就會被自己的手速拖累思緒。所以，練吧。

總結#

我們花了不少篇幅描述把 TDD 操作好需要哪些能力。事實上，這些能力並不專屬於 TDD，而是所有優秀開發者都該具備的。一旦練起來，不管是 ADD、BDD 還是其他什麼 DD，都不會難倒你；到那時候，是不是 TDD 反而沒那麼重要了。所以身為開發者，把該做的做好、該練的練好，流程自然就學得快、用得好。

原文出處#

原書/iThome：https://ithelp.ithome.com.tw/articles/10267463