第 4 / 6 部 待錄

技術實踐的安全繩

《Clean Agile》Podcast 準備稿：技術實踐的安全繩

書名： Clean Agile 敏捷整潔之道（Back to Basics） 作者： Robert C. Martin（Uncle Bob） 系列： Reading Uncle Bob（恩普拉氏） 公開標題建議： Reading Uncle Bob｜Clean Agile．TDD 與重構：敏捷真正的引擎 (4/6) 涵蓋範圍： 第5章 Technical Practices（TDD、Refactoring、Simple Design、Pair Programming）

背景速覽

這是《Clean Agile》第四集，進入 Circle of Life 最內環——技術實踐。這一章是整本書 Uncle Bob 講得最斬釘截鐵的部分，因為這是他的主場（他是 SOLID、TDD 推廣的核心人物）。四個實踐：TDD、Refactoring、Simple Design、Pair Programming。全章的論點只有一句話：沒有技術實踐的敏捷，注定失敗。 很多團隊以為敏捷就是站立會議＋Sprint＋看板，跳過技術實踐——結果無一不死。這集要講清楚，為什麼這四個「寫 code 的紀律」才是敏捷真正的引擎。

一句話重點

敏捷的業務實踐是一台「極度高效地製造混亂」的機器——它讓你飛快地產出大量程式碼；而技術實踐（TDD、重構、簡單設計、結對）是配套的「安全繩」，沒有它，你只會更快地把系統推進不可逆的死亡螺旋。

值得討論的重點

1. TDD 的三條規則，與「複式簿記」的類比

Uncle Bob 把 TDD 類比成會計的複式簿記——每筆交易記兩次（借方、貸方），相減為零才對帳成功。TDD 一樣：每個行為記兩次（一次是測試、一次是正式碼），一起跑結果應是「零失敗」。三條規則：(1) 不寫任何正式碼，除非先有一個因缺它而失敗的測試；(2) 測試只寫到剛好失敗（編譯失敗也算）；(3) 正式碼只寫到剛好通過。結果是極短的循環（數秒一輪），任何時刻你的 code 距離「全部通過」不超過一分鐘。這個類比很精彩，因為它說明 TDD 不是「測試技術」，而是一種逐步、可驗證、有對帳機制的工作紀律——就像會計師不會記完一整本帳才對一次餘額。

2. TDD 真正的禮物是「勇氣」，不是「測試覆蓋率」

書裡列了 TDD 一堆效益（減少除錯、活文件、樂趣、完整性、驅動設計），但 Uncle Bob 說最重要的是勇氣（Courage）。為什麼？回扣前面講過的「無懼的能力」——看到爛 code，你的第一個念頭是「該清理」，第二個念頭是「但我不敢碰」。TDD 就是那個「按一下幾秒就知道紅燈綠燈」的按鈕。有了它，你敢清理、敢重構、敢動別人的 code。沒有它，程式碼只會持續腐化成義大利麵，直到不得不全面重寫。還有一條深刻洞見：可測試性本質上就是解耦（testability = decoupling）——先寫測試會逼你把 code 設計成容易測的結構，所以 TDD 其實是一種「設計技術」。

3. Red / Green / Refactor：讓「能動」和「乾淨」分開處理

重構是在「不改變行為」前提下改善結構，它跟 TDD 交織成 Red/Green/Refactor 循環：寫失敗測試（Red）→ 用最簡單甚至最醜的方式讓它通過（Green）→ 回頭清理（Refactor）→ 再來一輪。核心洞見是：「讓 code 能動」和「讓 code 乾淨」是兩個獨立維度，同時追求太難，所以先用任何手段讓它綠，再回頭清。最重要的紀律：Refactoring 是持續進行的，不是排程活動——你不會在計畫裡看到「重構」這個工作項目，也不會連續好幾天製造混亂再一次清理，而是每隔一兩分鐘清理剛才的小混亂。連大規模重構（換架構）也是一小步一小步地遷移，期間系統始終保持所有測試通過、隨時可部署。

4. Simple Design 四規則 與 Pair Programming 的真實成本

Kent Beck 的 Simple Design 四規則（按優先序）：通過所有測試 → 揭示意圖 → 消除重複 → 減少元素。關鍵是「Design Weight（設計重量）」——設計複雜度會增加認知負擔，但適度的設計複雜度能降低需求複雜度的負擔，兩者不是簡單相加，目標是找平衡點讓整體最小化。至於結對，最值得講的是「成本帳」：研究顯示配對直接成本約 15%（115 個配對開發者約等於 100 個獨立工作者），若團隊 50% 時間配對，生產力損失不到 8%；但如果配對取代了 Code Review，生產力可能完全不受影響——因為配對本身就是一種「即時、動態的 Code Review」。再加上交叉訓練、防止知識孤島的無形效益，整體通常划算。還有那句很重要的話：永遠不要為了寫測試、重構或結對去向管理者請求許可——你是專家，這是你的專業判斷。

注意事項

⚠️ 測試覆蓋率是團隊指標，不是管理指標。 書裡兩次警告：管理者不該把覆蓋率當 KPI 或目標，否則開發者會為了衝數字而減少測試裡的斷言（assertion），甚至寫一堆跑過 code 卻不驗證任何東西的假測試。更別因為覆蓋率不足就讓 build 失敗——這只會逼開發者移除斷言來拉高數字，適得其反。這是 Goodhart’s Law 的經典案例：「當一個量測變成目標，它就不再是個好量測。」

⚠️ TDD 三規則初聽會讓人覺得「太教條、太慢」。要幫聽眾框對：這是學習階段的訓練輪，目的是內化「測試先行」的肌肉記憶。熟練後節奏會快到你幾乎感覺不到——重點是那個「任何時刻離綠燈不超過一分鐘」的安全感，不是死守每一秒的儀式。

⚠️ Pair Programming 別賣成「強制每個人時時刻刻配對」。書裡的原則很明確：自願參與、間歇進行（30%~80% 都合理）、自然形成（不由管理者排程）、短期合作。把配對排成強制制度，反而違背它的精神。Mob Programming（三人以上一起解一題）是選項，不是規定。

專家補充

💡 「可測試性即解耦」這條，是連接《Clean Agile》和《Clean Architecture》最重要的橋。你為了測試而被迫做的依賴反轉、介面抽離，正是 SOLID 裡 D（依賴反轉原則）的實作動機。所以 TDD 不只是測試紀律，它是架構壓力的來源——好的測試會把壞的架構逼出來。這條值得展開，因為它說明了為什麼 Uncle Bob 把 TDD 放在所有實踐的核心。

💡 「複式簿記」這個類比有歷史厚度——複式簿記是文藝復興時期（1494 年，Luca Pacioli 著作）的發明，被認為是現代資本主義的會計基石。Uncle Bob 用它類比 TDD，等於是說：TDD 之於軟體，可能就像複式簿記之於商業——一個讓「錯誤無所遁形」的紀律性發明。這個比喻的野心很大，值得點出。

💡 TDD 並非沒有爭議。2014 年 David Heinemeier Hansson（Rails 之父）寫了著名的〈TDD is dead〉，引發他、Kent Beck、Martin Fowler 三人的系列對談（“Is TDD Dead?”）。批評集中在「測試先行有時會傷害設計」「過度 mock 導致脆弱測試」。這是這集最好的「反方平衡」——可以誠實告訴聽眾：TDD 是強大的紀律，但「測試先行 vs 測試後寫」「該不該 100% TDD」在業界仍有正當的辯論，重點是吸收它的價值（快速回饋、勇氣、可測試性），而非教條照搬。

討論問題

🎙️ 開場鉤子：「很多人以為敏捷就是開站立會議、跑 Sprint、貼看板——然後失敗了還不知道為什麼。Uncle Bob 說：因為你跳過了真正的引擎。今天講敏捷裡最硬、也最被忽略的一塊：技術實踐。」

🎙️ 自問自答：「TDD 最大的好處是『高覆蓋率』嗎？」——不是。是勇氣。是那個讓你敢動爛 code、敢重構、敢清理的安全繩。覆蓋率只是副產品，把它當目標反而會毀掉測試。

🎙️ 拋給聽眾：「你上次不敢動某段 code，是什麼時候？那個『改了會壞、壞了變我的責任』的恐懼——TDD 想給你的，就是消除那個恐懼的按鈕。你有那個按鈕嗎？」

🎙️ 帶走的一題：「這禮拜挑一個小功能，試一次完整的 Red/Green/Refactor：先寫一個會失敗的測試，用最醜的方式讓它綠，再回頭清。體會一下『能動』和『乾淨』分開處理的感覺。」

更大範圍關聯

  • Reading Uncle Bob 路線：本集是 Circle of Life 最內環，也是整套敏捷的引擎室。它向前接《Clean Code》（測試章、重構案例）、向後接《Clean Architecture》（可測試性即解耦 → SOLID 的 D），是系列三本書的技術交會點。下一本《Clean Craftsmanship》整本書就在教 TDD/重構/簡單設計的細節。
  • TDD/重構經典：Kent Beck《Test-Driven Development by Example》（TDD 原典）、Martin Fowler《Refactoring》（重構聖經，壞味道型錄＋手法）、《Working Effectively with Legacy Code》（Michael Feathers，在沒測試的遺留系統裡建立測試）。
  • 反方辯證：DHH〈TDD is dead〉與 “Is TDD Dead?” 三人對談、John Ousterhout《A Philosophy of Software Design》（對「測試驅動設計」的保留看法）。整季埋的「帶腦讀經典」基調在這集可以再強化一次。
  • 簡單設計脈絡：Simple Design 四規則接 Kent Beck《Extreme Programming Explained》；Design Weight 接 Ousterhout 的「複雜度」分析、《A Philosophy of Software Design》的深淺模組之辯。
  • 在 [軟體工程領域切分藍圖] 的位置：這集橫跨「測試工程」「重構/程式碼品質」「結對/協作」三格，是把「設計品質」與「敏捷流程」綁死的關鍵章——也是 Software Craftsmanship 運動（EP6）的技術根基。

錄製建議

  • 建議時長：約 22 分鐘。配比：TDD（三規則＋複式簿記＋勇氣）約 10 分（絕對主菜）、Refactoring/Red-Green-Refactor 約 5 分、Simple Design 約 3 分、Pair Programming（成本帳）約 4 分。
  • 討論策略：開場戳破「敏捷=儀式」的誤解，立刻立論「技術實踐才是引擎」。TDD 用「複式簿記」類比建立縱深，再用「勇氣」這個情感點收服聽眾——這是整集的記憶錨。覆蓋率的警告（Goodhart’s Law）和 TDD 的反方辯論（DHH）一定要講，這是整季「帶腦讀經典」誠實度的展現。Pair 的「15% 成本但可取代 Code Review」是個漂亮的反直覺數字，適合做亮點。
  • 這集是整本書技術密度最高的一集，務必多舉具體例子、放慢 TDD 三規則的講解。提醒聽眾：這四個實踐少了任何一個，敏捷都會漏氣——它們是一個整體。