第 6 / 9 部 待錄

協作編程與驗收測試

《Clean Craftsmanship》Podcast 準備稿：協作編程與驗收測試．紀律的最後一哩

書名： 整潔的軟體工藝 Clean Craftsmanship（Disciplines, Standards, and Ethics） 作者： Robert C. Martin（Uncle Bob） 系列： Reading Uncle Bob（恩普拉氏） 公開標題建議： Reading Uncle Bob｜Clean Craftsmanship．結對只降 15% 生產力，卻買到什麼 (6/9) 涵蓋範圍： Part I 第7章 Collaborative Programming ＋ 第8章 Acceptance Tests（Part I 紀律收尾）

背景速覽

Part I 的前五個紀律都很「技術」（TDD、重構、設計），這集講最後兩個——也是最「人」的兩個：協作編程（結對/群組）與驗收測試（連結開發與業務）。Uncle Bob 說協作編程是五大紀律中技術性最低、卻可能最重要的一個；驗收測試則是最技術化的業務實踐。這集把 Part I 收尾，主軸從「個人怎麼寫好 code」拉到「團隊怎麼共享知識、怎麼跟業務對齊」。

一句話重點

結對/群組編程的數據很反直覺——生產力只掉約 15%（遠低於大家擔心的 50%），卻換來缺陷少 15%、程式碼量少 15%、以及最珍貴的「知識在團隊裡流動、沒有人是不可替代的孤島」；而驗收測試則挑明一個殘酷真相：真正的需求就是那些測試，需求文件寫什麼不重要，QA 簽核通過才算數。

值得討論的重點

1. 協作編程：用 15% 的生產力換品質與抗風險

Uncle Bob 用球隊隱喻開場：球員絆倒了，其他人會補位，球繼續前進——團隊就該這樣。協作編程（兩人叫 Pair、三人以上叫 Mob）的關鍵數據值得逐條講，因為它直接打臉「兩個人做一件事很浪費」的直覺：

  • 生產力下降約 15%（不是大家怕的 50%）
  • 缺陷減少約 15%
  • 程式碼量減少約 15%（結構更好）

後兩項暗示產出的程式碼結構顯著優於獨自工作——這不只是效率問題，是品質問題。實務建議也很具體：協作別佔 100%（建議 20%-70%，看團隊成熟度）、每次會議 10 分鐘到 1-2 小時、用番茄鐘切（1-3 個番茄）、沒有人主導、鍵盤頻繁輪換、可同時當「即時練習 + 即時 code review」。組合也有講究：資深+資淺很划算（資深被拖慢一場會議，資淺被加速一輩子）；資深+資深要「確保房間裡沒有武器」（Uncle Bob 的幽默）。

2. 驗收測試：你的測試才是真正的需求

這章的核心洞見很尖銳：很多組織靠 QA 跑一堆手動測試決定能不能上線——那麼系統的真正需求就是那些測試，不管需求文件寫了什麼。驗收測試的紀律就是認清這件事，主張「所有需求都用測試的形式來規格化」。角色分工很清楚：BA 寫 Happy Path、QA 寫各種失敗場景，在開發的同時或略早寫好；程式設計師負責自動化這些測試，而且自動化的語言必須是 BA/QA 看得懂、最好能自己寫的（FitNesse、Cucumber、SpecFlow 等）。這些測試就成了「Done 的定義」——全過才算完成。最後接到持續建置：測試一旦通過就進 CI，每次簽入自動跑，「允許失敗在持續建置中累積是自殺行為」。

3. 兩個紀律的共同精神：消除孤島、對齊真相

把這兩章放一起講有個漂亮的共同主軸：消除資訊孤島。協作編程消除「只有 Bob 懂這塊」的人員孤島；驗收測試消除「需求文件說一套、實際驗收標準另一套」的需求孤島。兩者都在做同一件事——讓系統的真相透明地共享給整個團隊與業務端，這樣團隊才能像球隊一樣補位、才能對著同一個「完成」的定義前進。

注意事項

⚠️ 「結對只降 15% 生產力」這個數字要誠實標註來源強度。Uncle Bob 引的是學術研究（主要是 Laurie Williams 等人 2000 年代的實驗），但這些實驗多在受控環境、特定任務上做，外推到所有團隊要打折。而且他自己也承認「沒看過群組編程（Mob）的正式研究，只有軼事證據」。講的時候可以說：這個數字方向上可信（結對沒有大家怕的那麼貴），但別當成精準的 KPI。

⚠️ 協作編程不適合所有人，這點 Uncle Bob 難得地給了空間——有些人獨自工作效果更好，不該強迫、也不該貶低（這類人通常在 Mob 裡比在 Pair 裡自在）。要提醒聽眾：把結對當成強制 KPI 來推，往往適得其反；它是團隊文化的選項，不是打卡指標。遠距時代還多了一層挑戰（螢幕共享能做，但長時間高強度結對更累）。

⚠️ 「驗收測試由 BA/QA 撰寫、程式設計師自動化」是理想分工，現實裡能做到的團隊很少。FitNesse 那一派的「business-readable 測試」在很多組織推不動（BA/QA 不寫、工具維護成本高）。本章自己也給了務實的漸進路線（初期程式設計師代寫 → 中期 BA/QA 能讀能認可 → 最終能自己寫）。講的時候別把「最嚴格形式」當成唯一正解，「能讀能認可」其實就已經拿到八成價值。

專家補充

💡 協作編程的「缺陷少 15%、程式碼量少 15%」這組數據，最值得放大的不是省了多少 bug，而是它揭示了一個常被忽略的事實：code review 在事後做，不如 code 在生成的當下就被第二雙眼睛看著。結對本質上是「即時、連續的 review」，它在問題還沒長大時就掐掉——這比 PR 階段才發現、來回拉扯要便宜得多。這也呼應後面「勇氣」章的「互相補位是你的責任」。

💡 「真正的需求就是那些測試」這句，是整本書最有衝擊力的觀念之一，可以連到一個更大的命題：規格（specification）與測試（test）本來就該是同一個東西。這正是 BDD 與「可執行規格（executable specification）」運動的核心信念——文件會過期、會說謊，但能跑的測試不會。Gojko Adzic《Specification by Example》把這條線講得最透。

💡 給聽眾的落地建議：不必一步到位導入完整的驗收測試框架。最低成本的入門是「每個 user story 在開工前，先跟 PM/QA 把『怎樣算做完』寫成三五條具體的 Given-When-Then」——光是這個動作，就能擋掉大量「做完了才發現理解錯」的悲劇。

討論問題

🎙️ 開場鉤子：「兩個工程師盯著同一個螢幕寫一段 code，聽起來很浪費對吧？研究說生產力只掉 15%，卻換來品質提升——這筆帳該怎麼算？」

🎙️ 自問自答：「你們團隊的『真正需求』寫在哪？」——多半不在那份沒人看的需求文件裡，而在 QA 上線前跑的那組測試裡。承認這件事，是寫好驗收測試的起點。

🎙️ 拋給聽眾：「如果你明天請假，團隊會不會卡住某一塊只有你懂的東西？Uncle Bob 說：確保有人能替你補位，是『你的』責任，不是主管的。」

🎙️ 帶走的一題：「下一個 story 開工前，花十分鐘跟 PM 把『做完的定義』寫成三條具體的 Given-When-Then。先別管工具，先把『完成』講清楚。」

更大範圍關聯

  • 協作編程的延伸：Mob Programming 的代表作是 Woody Zuill 的實踐與分享；結對的學術根據可追 Laurie Williams & Robert Kessler《Pair Programming Illuminated》。
  • 驗收測試/可執行規格：Gojko Adzic《Specification by Example》、以及 BDD 創始人 Dan North 的 Given-When-Then——這集的驗收測試其實就是 BDD 在團隊流程上的落地。
  • 同系列接點：本章的「互相補位」會在 Part II 的 Courage 章（We Cover for Each Other）與 Part III 的 Teamwork 章（Promise 7）再次出現——協作編程是那兩個倫理承諾的技術手段。
  • 領域定位：用 [軟體工程領域切分藍圖] 看，這集橫跨「團隊協作/流程」與「測試」兩塊，是 Part I 從「個人技藝」過渡到 Part II「對團隊與世界的標準」的轉折點。

錄製建議

  • 建議時長：約 18-20 分鐘（兩章都偏短，合併剛好）。配比：協作編程數據與實務 9 分、驗收測試與 CI 7 分、兩者共同精神（消除孤島）3 分。
  • 討論策略：用「15% 數字」當鉤子最反直覺、最抓耳。協作編程多講具體的「怎麼做」（番茄鐘、輪鍵盤、組合搭配），別停在理論。驗收測試的記憶點就是那句「真正的需求就是那些測試」，務必講透。這是 Part I 收尾集，結尾花 30 秒回顧七大紀律走完一遍，預告下集翻頁進 Part II——「Bob Martin 當你的 CTO，他對你有什麼期望」。