專業編程領域總是產生一些相當激烈的爭論。例如關于是否以及怎樣對代碼作注釋。我們很難平息這些爭論，因為科學地論證專業編程是有難度的。我們不可能真的要求大公司用一個對照組與一個實驗組兩次構建同一個軟件。因此很多時候我們的依據是傳聞或個人意見，極缺經驗數據。因此，相比是否該選擇結對編程，今天我更想談談結對編程的模式。

[[207055]]

我先前曾從業務角度談論過結對編程的好處，現在我以同樣的方式來介紹今天這篇文章。你能從中獲益，但你必須評估它對你是否有意義。要想做好評估，你就應該了解不同的結對編程模式以及它們都是如何運作的。

沒錯，結對編程并非只是把兩個人扔一起、讓他們瘋狂撒歡。多年以來，從業者開發了一些應用于不同情況的技術，通過實踐與實驗，他們對這些技術作了提高與完善。

一、熟練程度不同結對編程模式的影響

看實際方案之前，讓我們先繞個小彎看看不同開發人員的技術水平。盡管我們看似特別傾向于細致地區分不同技術水平，但我覺得實際只存在兩種開發人員技術水平：初學者和專家。我懂，我懂，你們一定覺得這種分法太草率了，但這樣確實可以把復雜性降到***，且能很好地解釋不同結對模式。根據我們這兩種技術水平，能得出以下三種結對組合：

• 專家-專家
• 專家-初學者
• 初學者-初學者

請注意，我這里談及的專業技術，是背景的一部分，而不僅僅是一般的行業經驗。技術的積累、對代碼庫的熟悉程度、甚至還有專業領域知識在這都很重要。我有兩個計算機科學學位，對幾種面向對象的編程語言也有數年經驗，但如果我哪天加入你的Go語言團隊，你可以妥妥地把我放在初學者陣營直到我找到自己的定位。

每種結對模式有它的優缺點，然而有時候命運可能迫使你根據哪個人有空來做出選擇，到時候對不同結對模式的了解會助你更有效率。另外，值得一提的是，初學者-初學者的組合可為二者提供很多的學習機會，但有風險。因此，這種組合的適用性更多地取決于你對風險而非結對模式本身的傾向。

二、非結構化結對模式

設想一下結對編程誕生時的情況，李四走到張三的格子間辦公室，說：“嗨，我們一起用FORTRAN語言工作吧。”好吧，這么個小故事也許不足為信，不過想象一下它會怎么發展吧。李四和張三習慣把編程作為獨自的工作，某天卻決定把他們的智慧結合在一起。他們不一定知道任何編程協作的技巧，所以他們臨時結伙，試著互相幫助。

這是我要列舉的***種協作示例。如果覺得很荒唐，那你要錯過這堂課了。知道一些技巧可以嘗試當然很有幫助，但不要麻痹了你的分析能力。如果你想起步，試錯(測試與出錯)會有很大幫助。就像下面的結對技巧通過試錯而不斷進步，你自己也需要這樣。

但也要知道結對的組成中也存在著限制。它需要兩個夠格的頭腦和單單一臺計算機，所以當你在編程而你的伙伴在檢查她的郵件是不行的。你可以視情況用些不同的溝通技巧，如“鍵盤用一個還是兩個?”、“誰來打代碼?在什么時候?”

三、駕駛員-***員模式

就已建立的模式而言，我們先來看一下駕駛員-***員模式。理論上這可構成最成熟的模式。

它的名字源于兩個人可能作汽車旅行穿越未知區域的場景，駕駛員的注意力集中在機械方面，包括操控油門和剎車，調轉車輪還有提防障礙與其他車輛。與此同時，***員則考慮更宏觀的問題。還要開多久才能下高速?手機是否能及時收到任何突發交通堵塞的提示?

把這對關系的比喻應用于編程，那么駕駛員就負責寫代碼，瀏覽文件，還有基礎實現方法。***員則著眼更長遠的考慮并且檢查錯誤。這方法適合這種架構嗎?我們有沒有可能另辟蹊徑重寫一個實現方法?我們是否困在死胡同里了?

如果二者都是可互換角色的專家，那么駕駛員-***員模式會很理想，對于專家與新手的組合來說也不錯。這個模式在專家做***員時最容易起效，因為讓菜鳥來當***員，他可能只會被動地干坐著而讓專家分飾兩角。

四、后座***員模式

接下來要講的結對編程模式是后座***員模式。這方案看起來像是駕駛員-***員模式，但***員接管了更多具體策略的工作(讓人聯想到后座駕駛員)。

和駕駛員-***員模式一樣，駕駛員在鍵盤前坐著，執行諸如寫代碼的工作。但不像駕駛員-***員模式，后座***員下達的是更細致的指示。這意味著她可能告訴駕駛員什么時候創建一個方法或打開一個新的文件。她還會告訴他應該如何為一個測試或變量命名。

這種模式在以初學者為駕駛員的初學者-專家組合中發揮得***。初學者在按照專家指示做事的過程中得到學習。

五、向導模式

另一種非常適合專家-初學者組合的模式是向導模式。同樣，駕駛的比喻依然適用。

設想去某地度假并在當地旅行。駕駛員登上客車或巴士，開始駕駛，然后告訴你他正在做的每件事情和你所看到的每樣事物。你的地位就很被動。

向導模式編程模式也是這樣。駕駛員做戰略與策略上的思考，同時寫代碼。當她這么做時，她告訴“游客”她正在做什么。游客很少介入。

這在專家駕駛員與菜鳥游客組合上很有效，尤其是菜鳥一無所知的情況下。但如果角色互換，它其實也同樣有效。初學者可以在專家的觀察下探索解決問題，專家則提供反饋與糾正，如此反復。

六、乒乓結對模式

要認真完成結對編程模式的學習，你還得了解乒乓結對模式。這種模式有個不同于其他模式的有趣因素。

為了便于理解，把結對編程看成一項極限編程運動，這些人深愛著結對編程和其他具體應用，如單元測試。因此當你遇到一個極限編程者，你可以穩妥地認定她喜歡結對也喜歡實踐測試驅動開發(TDD)。

這個步調很簡單，前一個人寫一個失敗測試而后一個人設法通過。接著后一個人寫失敗測試讓前一個人設法通過。如此來回往復，有點像乒乓球。

這種模式在兩個專家的組合時進行得格外***，初學者-專家組合也進行得相當順利。另外很有趣的是，它可能在初學者-初學者組合下效果***，前提是以鍛煉初學者為目的。乒乓結對模式下，兩人角色轉換得非常頻繁，使得他們總能一起思考，因此所有的組合都能進行順利(盡管會帶來一些人際關系問題)。

七、分布式模式

我將以一種“非正式”的結對模式收尾。不過這種配對模式極有可能掌握著未來日益全球化的分布式世界的關鍵，我說的正是分布式結對模式。

極限編程始于90年代，當時，遠程工作需要Citrix系統與撥號調制解調器。換言之，你在任何地方都做不了協作編程工作，只能由個人完成。但20年后，托管的硬性要求隨著技術發展而弱化了。你可以用Screen Hero之類的軟件無縫銜接。顯然，就個人而言，協作仍然更有效，但技術已經縮小了很大的差距。另外，人們隨時隨地協作產生的長遠收益是不可否認的。

相信在未來，結對編程模式還需要加入經得起考驗的技術。不過我認為分布式模式會變得更加多元化。前面幾種模式隨著時間推移均進行了技術的更新與完善。我認為不到20年，我們將看到一些頗明智且復雜巧妙的結對編程模式。