所有協同建構（Collaborative Construction）技術的核心理念都是相同的：開發者對自身的盲點視而不見，而其他人不會有相同的盲點。研究顯示，開發者平均每小時在設計中引入 1-3 個缺陷、在程式碼中引入 5-8 個缺陷。將作品展示給他人檢視，是攻克這些盲點最有效的手段。

21.1 協同開發實踐概要#

協同建構對品質的補強效果#

單獨使用測試的平均缺陷偵測率並不高：單元測試約 30%、整合測試約 35%、低量 Beta 測試約 35%。相比之下，設計審查與程式碼審查的平均偵測率分別為 55% 和 60%。

協同實踐不僅能發現更多缺陷，還能找到與測試不同類型的錯誤——例如不清楚的錯誤訊息、不足的註解、寫死的變數值、以及應該整合的重複程式碼模式。即使測試做得很好，審查仍是全面品質計畫中不可或缺的一環。

歷年來的研究數據令人印象深刻：

• IBM 發現每小時的審查可以節省約 100 小時的後續工作（測試與缺陷修正）。
• Raytheon 透過審查計畫將返工成本從專案總成本的 40% 降至 20%。
• HP 報告其審查計畫每年節省約 2150 萬美元。
• 一項大型程式研究發現，每小時審查可避免平均 33 小時的維護工作，審查效率最高可達測試的 20 倍。
• 引入程式碼審查後，單行修改的錯誤率從 55% 降至 2%；所有修改的首次正確率從不到 20% 提升至 95%。
• Capers Jones 指出：所有達到 99% 以上缺陷移除率的專案都使用了正式審查，而缺陷移除率低於 75% 的專案都沒有使用。

協同建構的附加價值#

• 指導與文化傳承：審查是讓資深與資淺工程師交流技術議題的場域，也是推動程式碼標準實際落地的機制。
• 集體所有權（Collective Ownership）：程式碼歸團隊而非個人所有，好處包括：多人審視帶來更高品質、降低人員離職衝擊、縮短缺陷修正週期。
• 不僅限於建構階段：協同技術同樣適用於估算、計畫、需求、架構、測試與維護工作。

21.2 結對程式設計#

結對程式設計（Pair Programming） 是由一人輸入程式碼、另一人即時監看錯誤並進行策略性思考的開發方式。初期研究顯示其品質水準接近正式審查，成本比單獨開發高約 10-25%，但開發時間可縮短約 45%。

成功的關鍵原則#

結對的好處#

• 在壓力下仍能維持程式碼品質。
• 可讀性與可理解性提升至團隊最佳水準。
• 縮短時程（寫得更快、錯誤更少、末期修正更少）。
• 同時享有指導新人、傳承文化、促進集體所有權等附帶效益。

21.3 正式審查#

正式審查（Formal Inspection） 由 Michael Fagan 在 IBM 開發，是經實證驗證最有效的缺陷偵測技術之一。個別審查通常能捕捉約 60% 的缺陷；設計審查加程式碼審查的組合通常可移除 70-85% 或更多的缺陷。審查大約佔專案預算的 10-15%，但通常能降低整體專案成本。

審查與一般檢視的差異#

• 使用檢查表（Checklist） 聚焦於過去常見的問題領域。
• 專注於缺陷偵測而非修正。
• 審查者事先準備，帶著已發現的問題清單出席。
• 每位參與者都有明確的角色。
• 主持人不是作者本人，且受過專門的主持訓練。
• 僅在所有參與者都已充分準備時才召開會議。
• 收集數據並回饋至未來的審查流程中。
• 管理層不參與審查會議。

角色分配#

審查結果絕不可用於績效考核。程式碼在審查時仍在開發中，應基於最終產品評估績效，否則將扼殺審查的效果。

人數建議：不少於 3 人，傳統建議不超過 6 人。研究顯示超過 2-3 位審查者通常不會增加發現的缺陷數量。

審查的一般流程#

1. 規劃（Planning）：主持人決定審查者名單、時間地點，分發材料與檢查表。
2. 概覽（Overview）：若審查者不熟悉專案，作者可花約一小時介紹技術背景（但應謹慎使用，避免掩蓋不清楚之處）。
3. 準備（Preparation）：每位審查者獨立研讀，使用檢查表引導。應用層程式碼約每小時 500 行，系統層程式碼約每小時 125 行。可指定不同觀點（維護者、客戶、設計者）或情境來引導準備。
4. 審查會議（Inspection Meeting）：由非作者的人逐段說明設計或程式碼。一旦確認為缺陷即停止討論並記錄，不在會議中討論解決方案。最佳審查速率約每小時 150-200 行非空白非註解的原始碼。會議不超過兩小時，同一天不安排多場。
5. 審查報告（Inspection Report）：會議後一天內，主持人產出報告列出每個缺陷的類型與嚴重度。
6. 返工（Rework）：缺陷指派給負責人（通常是作者）修正。
7. 追蹤（Follow-Up）：主持人確認所有返工已完成，依嚴重程度決定是否需要重新審查。
8. 第三小時會議：非正式的討論時間，讓有興趣的人討論解決方案。

flowchart LR
    A["規劃"] --> B["概覽"]
    B --> C["準備"]
    C --> D["審查會議"]
    D --> E["審查報告"]
    E --> F["返工"]
    F --> G["追蹤"]
    G --> H{"需重新審查？"}
    H -->|"是"| C
    H -->|"否"| I["完成"]

微調與自我反省#

• 隨著審查經驗累積，持續根據數據優化檢查表——新增常見錯誤類型、移除不再出現的項目。
• 檢查表不超過一頁。
• 不要在沒有量測的情況下更改審查流程。

關於自尊心（Ego）的管理：審查的目的是發現缺陷，不是批評作者。作者應預期會聽到一些不是真正缺陷的批評，最好的做法是先記下再私下判斷其是否有效。審查者則必須尊重作者對如何修正缺陷的最終決定權。

21.4 其他類型的協同開發實作#

走查（Walk-Through）#

走查的定義很鬆散，從非正式的白板討論到有正式簡報的排程會議都算。共通特徵包括：

• 通常由作者主持（這是與審查的主要差異）。
• 聚焦技術議題，所有人事先準備。
• 持續約 30-60 分鐘，強調錯誤偵測而非修正。
• 管理層不參與。

走查的缺陷偵測率約 20-40%，顯著低於正式審查。當團隊有不好的技術審查經驗時，幾乎都是與走查等非正式實踐有關。

如果工作成果值得開會審查，就值得用正式審查；如果不值得正式審查的開銷，那也不值得開會，改用程式碼閱讀等互動性較低的方式更好。

走查仍適用的場景：審查群體很大需要多元觀點時、或審查者來自外部組織不熟悉正式審查流程時。

程式碼閱讀（Code Reading）#

程式碼閱讀的重點在個人獨立審閱而非會議。流程如下：

1. 作者分發 1000-10,000 行原始碼（通常 4000 行）。
2. 至少兩位讀者獨立閱讀，速率約每天 1000 行。
3. 會議由作者主持，約 1-2 小時，聚焦討論讀者發現的問題。不逐行走查，會議甚至不是嚴格必要的。
4. 作者修正被識別的問題。

NASA 的研究發現程式碼閱讀每小時偵測約 3.3 個缺陷（測試僅 1.8 個），且在專案生命週期中比測試多找出 20-60% 的錯誤。AT&T 的研究更指出 90% 的缺陷是在準備階段發現的，僅 10% 在會議中發現——這正是程式碼閱讀強調個人審閱的合理性。程式碼閱讀對地理分散的團隊尤其有價值。

客戶展示（Dog-and-Pony Show）#

向客戶展示軟體產品的管理性審查，常見於政府合約。不要依賴它來改善技術品質。

21.5 協同建構技術的比較#

結對程式設計與正式審查若在品質、成本與時程上產出相似結果，選擇就取決於團隊的工作風格偏好。有些人偏好獨立工作搭配偶爾的審查會議，有些人偏好更多直接協作。團隊內的不同小組可以各自選擇最適合的方式。

更多資源#

• Williams, L. & Kessler, R. Pair Programming Illuminated (2002)：結對程式設計的詳盡指南，涵蓋各種性格搭配的應對方式。
• Wiegers, K. Peer Reviews in Software: A Practical Guide (2002)：涵蓋正式審查與非正式實踐，研究紮實且實務導向。
• Gilb, T. & Graham, D. Software Inspection (1993)：1990 年代初的審查全面討論，含多個組織的導入案例。
• Fagan, M. “Design and Code Inspections to Reduce Errors in Program Development” (1976) 與 “Advances in Software Inspections” (1986)：審查方法的原始論文。

要點#

• 協同開發實踐的缺陷偵測率通常高於測試，且效率更高。
• 協同實踐與測試發現的錯誤類型不同，兩者都需要才能確保軟體品質。
• 正式審查透過檢查表、準備、明確角色與持續流程改善來最大化偵測效率，效果通常優於走查。
• 結對程式設計的成本與效果大致與正式審查相當，在需要縮短時程時尤其有價值。
• 正式審查不僅適用於程式碼，也適用於需求、設計與測試案例等工作產物。
• 走查與程式碼閱讀是審查的替代方案；程式碼閱讀在善用每個人時間方面更具彈性。