🎯 什麼情境該想到我
當你「等審查等到程式碼都過時了，或者手上這段程式難到需要第二雙眼睛即時盯著」的時候。
⚙️ 怎麼用（步驟 / 公式）
意圖：讓審查發生在寫程式的當下，用「無法忽視坐在你旁邊的審查者」這個特性，把審查變成必然而非選擇。
定義：兩位工程師在同一台工作站上一起工作，這個方法由 Extreme Programming 與 Agile 在 2000 年代初期推廣。書中把 pairing 與 pair programming 兩詞交替使用，因為這個實踐不只給開發者用，價值流上任何工程師的工作都適用。
角色分工（常見模式）：
- driver：實際寫程式碼的人，可以把全部注意力放在完成任務的戰術面。
- navigator／observer／pointer：在工作進行中同步審查的人。他在審查的同時也會思考工作的策略方向，想出改進點子與可能的未來問題；對 driver 而言，他是安全網與嚮導。
- 當兩人專長不同時，技能會自動轉移——不論是透過臨時教學，還是分享技巧與變通做法。
另一種模式（強化 TDD）：一位工程師寫自動化測試，另一位工程師寫實作。
為什麼它比一般 code review 強（Jeff Atwood，Stack Exchange 共同創辦人）：
- 「結對程式設計是不是就是打了類固醇的 code review？它的優勢在於攫取式的即時性：當審查者就坐在你旁邊，你不可能忽視他。」
- 「多數人在有選擇時會被動地選擇不審查程式碼。結對時這不可能。每一半的人都必須在程式碼被寫下的當下、就在那裡理解它。結對可能很侵入，但它也能逼出你原本永遠達不到的溝通層級。」
關鍵數字（Dr. Laurie Williams，2001 年研究）：
- 結對的程式設計師比兩個各自獨立工作的程式設計師慢 15%；
- 但 「error-free」的程式碼從 70% 提升到 85%。書中補一句：既然測試與除錯的成本往往是初始開發的許多倍，這是相當可觀的結果。
- 結對者通常會考慮比獨自工作更多的設計方案，得到更簡單、更好維護的設計，也更早抓到設計缺陷。
- 96% 的受訪者表示結對工作時比獨自工作更享受。
- 額外好處：知識在組織中擴散、團隊內資訊流增加；讓較資深的工程師審查、較資淺的工程師寫程式，是有效的教與學方式。
實務排程（書中註腳）：
- 有些組織強制要求結對；有些則讓工程師在想要更多檢視的區域（例如 check in 之前）或困難任務時，自己去找人結對。
- 另一種常見做法：設定每天一段結對時段，例如從上午中段到下午中段的四小時。
案例：Pivotal Labs（2011）——用結對取代壞掉的 code review 流程
- Elisabeth Hendrickson（Pivotal Software 工程副總、《Explore It!》作者）主張讓每個團隊為自己的品質負責，而不是交給獨立部門；她認為這不只提升品質，也大幅增加流入生產環境的工作流量。
- 2011 年 Pivotal 有兩種被接受的 code review 方法：結對程式設計（確保每一行程式碼都被兩個人檢視），或由 Gerrit 管理的 code review 流程（確保每個 commit 都有兩位指定人員 +1 後才能進 trunk）。
- Gerrit 流程的問題：開發者常常要等整整一週才拿到必要的審查。有本事的開發者陷入「連簡單的變更都推不進程式庫」的挫折且磨人的經驗，因為他們無意間造出了無法忍受的瓶頸。
- Hendrickson 的描述：只有資深工程師有 +1 的權限，而他們有很多其他責任，往往不太在意資淺開發者在修的東西或他們的生產力。結果是——你在等審查的那一週，其他開發者一直在 check in，於是你得把他們的變更全部 merge 到自己的筆電上、重跑所有測試確認一切還能動，有時還得重新送審一次。
- 解法：他們拆掉整個 Gerrit code review 流程，改為要求用結對程式設計來實作程式碼變更。結果：取得程式碼審查所需的時間從數週降到數小時。
- 她的但書：code review 在許多組織裡運作良好，但那需要一種「重視審查程式碼一如重視當初寫程式碼」的文化；當那個文化還不到位時，結對程式設計可以作為有價值的過渡實踐（interim practice）。
原文：「programmers are 15% slower than two independent individual programmers,」（L9776，接 L9777「while ‘error-free’ code increased from 70% to 85%. Since testing and debugging」）
原文：「stated that they enjoyed their work more when they programmed in pairs than」（L9782）
原文：「they reduced the amount of time required to get code」（L9831，接 L9832「reviewed from weeks to hours.」）
原文：「pairing hours for a subset of the working day, perhaps four hours from mid-morning to mid-afternoon.」（L10009）
🧪 我實際套用的紀錄
- （待填）
⚠️ 注意 / 什麼時候不適用
- 會慢 15%（Williams 研究）——這是明確的成本，換來的是 error-free 比例從 70% 升到 85%；若你的瓶頸不在缺陷而在別處，這筆交易未必划算。
- 書中形容結對「可能很侵入（invasive）」；不是所有人、所有任務都適合全時結對，註腳也明說有些組織只在困難任務或 check in 前才結對。
- 結對不是 code review 的絕對優解：Hendrickson 明講 code review 在很多組織仍然有效，結對是文化未到位時的過渡實踐。
- Pivotal 拆掉 Gerrit 的真正病因是「只有資深工程師能 +1」造成的瓶頸，不是工具本身——先診斷瓶頸在哪，再決定要不要換做法。
🔗 相關工具
- 程式碼審查準則（結對是四種審查形式之一；審查排隊時可換成結對）
- 同儕審查取代變更審批（結對是「同儕審查」最即時的形式）
- 主幹開發（結對讓「進 trunk 前已被兩人看過」變成常態）
- 工具-心理安全感（全時共用一台機器需要很高的互信）
- DevOps手冊