本文轉自微信號EAWorld。掃描下方二維碼，關注成功後，回覆“普元方法+”，將會獲得熱門課堂免費學習機會！本文轉自微信號EAWorld。
專業編程領域總是產生一些相當激烈的爭論。例如關於是否以及怎樣對代碼作註釋。我們很難平息這些爭論，因爲科學地論證專業編程是有難度的。我們不可能真的要求大公司用一個對照組與一個實驗組兩次構建同一個軟件。因此很多時候我們的依據是傳聞或個人意見，極缺經驗數據。因此，相比是否該選擇結對編程，今天我更想談談結對編程的模式。
我先前曾從業務角度談論過結對編程的好處，現在我以同樣的方式來介紹今天這篇文章。你能從中獲益，但你必須評估它對你是否有意義。要想做好評估，你就應該瞭解不同的結對編程模式以及它們都是如何運作的。
沒錯，結對編程並非只是把兩個人扔一起、讓他們瘋狂撒歡。多年以來，從業者開發了一些應用於不同情況的技術，通過實踐與實驗，他們對這些技術作了提高與完善。
一、熟練程度不同結對編程模式的影響
看實際方案之前，讓我們先繞個小彎看看不同開發人員的技術水平。儘管我們看似特別傾向於細緻地區分不同技術水平，但我覺得實際只存在兩種開發人員技術水平：初學者和專家。我懂，我懂，你們一定覺得這種分法太草率了，但這樣確實可以把複雜性降到最低，且能很好地解釋不同結對模式。根據我們這兩種技術水平，能得出以下三種結對組合：
• 專家-專家
• 專家-初學者
• 初學者-初學者
請注意，我這裏談及的專業技術，是背景的一部分，而不僅僅是一般的行業經驗。技術的積累、對代碼庫的熟悉程度、甚至還有專業領域知識在這都很重要。我有兩個計算機科學學位，對幾種面向對象的編程語言也有數年經驗，但如果我哪天加入你的Go語言團隊，你可以妥妥地把我放在初學者陣營直到我找到自己的定位。
每種結對模式有它的優缺點，然而有時候命運可能迫使你根據哪個人有空來做出選擇，到時候對不同結對模式的瞭解會助你更有效率。另外，值得一提的是，初學者-初學者的組合可爲二者提供很多的學習機會，但有風險。因此，這種組合的適用性更多地取決於你對風險而非結對模式本身的傾向。
二、非結構化結對模式
設想一下結對編程誕生時的情況，李四走到張三的格子間辦公室，說：“嗨，我們一起用FORTRAN語言工作吧。”好吧，這麼個小故事也許不足爲信，不過想象一下它會怎麼發展吧。李四和張三習慣把編程作爲獨自的工作，某天卻決定把他們的智慧結合在一起。他們不一定知道任何編程協作的技巧，所以他們臨時結夥，試着互相幫助。
這是我要列舉的第一種協作示例。如果覺得很荒唐，那你要錯過這堂課了。知道一些技巧可以嘗試當然很有幫助，但不要麻痹了你的分析能力。如果你想起步，試錯（測試與出錯）會有很大幫助。就像下面的結對技巧通過試錯而不斷進步，你自己也需要這樣。
但也要知道結對的組成中也存在着限制。它需要兩個夠格的頭腦和單單一臺計算機，所以當你在編程而你的夥伴在檢查她的郵件是不行的。你可以視情況用些不同的溝通技巧，如“鍵盤用一個還是兩個？”、“誰來打代碼？在什麼時候？”
三、駕駛員-領航員模式
就已建立的模式而言，我們先來看一下駕駛員-領航員模式。理論上這可構成最成熟的模式。
它的名字源於兩個人可能作汽車旅行穿越未知區域的場景，駕駛員的注意力集中在機械方面，包括操控油門和剎車，調轉車輪還有提防障礙與其他車輛。與此同時，領航員則考慮更宏觀的問題。還要開多久才能下高速？手機是否能及時收到任何突發交通堵塞的提示？
把這對關係的比喻應用於編程，那麼駕駛員就負責寫代碼，瀏覽文件，還有基礎實現方法。領航員則着眼更長遠的考慮並且檢查錯誤。這方法適合這種架構嗎？我們有沒有可能另闢蹊徑重寫一個實現方法？我們是否困在死衚衕裏了？
如果二者都是可互換角色的專家，那麼駕駛員-領航員模式會很理想，對於專家與新手的組合來說也不錯。這個模式在專家做領航員時最容易起效，因爲讓菜鳥來當領航員，他可能只會被動地乾坐着而讓專家分飾兩角。
四、後座領航員模式
接下來要講的結對編程模式是後座領航員模式。這方案看起來像是駕駛員-領航員模式，但領航員接管了更多具體策略的工作（讓人聯想到後座駕駛員）。
和駕駛員-領航員模式一樣，駕駛員在鍵盤前坐着，執行諸如寫代碼的工作。但不像駕駛員-領航員模式，後座領航員下達的是更細緻的指示。這意味着她可能告訴駕駛員什麼時候創建一個方法或打開一個新的文件。她還會告訴他應該如何爲一個測試或變量命名。
這種模式在以初學者爲駕駛員的初學者-專家組合中發揮得最好。初學者在按照專家指示做事的過程中得到學習。
五、嚮導模式
另一種非常適合專家-初學者組合的模式是嚮導模式。同樣，駕駛的比喻依然適用。
設想去某地度假並在當地旅行。駕駛員登上客車或巴士，開始駕駛，然後告訴你他正在做的每件事情和你所看到的每樣事物。你的地位就很被動。
嚮導模式編程模式也是這樣。駕駛員做戰略與策略上的思考，同時寫代碼。當她這麼做時，她告訴“遊客”她正在做什麼。遊客很少介入。
這在專家駕駛員與菜鳥遊客組合上很有效，尤其是菜鳥一無所知的情況下。但如果角色互換，它其實也同樣有效。初學者可以在專家的觀察下探索解決問題，專家則提供反饋與糾正，如此反覆。
六、乒乓結對模式
要認真完成結對編程模式的學習，你還得了解乒乓結對模式。這種模式有個不同於其他模式的有趣因素。
爲了便於理解，把結對編程看成一項極限編程運動，這些人深愛着結對編程和其他具體應用，如單元測試。因此當你遇到一個極限編程者，你可以穩妥地認定她喜歡結對也喜歡實踐測試驅動開發（TDD）。
這個步調很簡單，前一個人寫一個失敗測試而後一個人設法通過。接着後一個人寫失敗測試讓前一個人設法通過。如此來回往復，有點像乒乓球。
這種模式在兩個專家的組合時進行得格外完美，初學者-專家組合也進行得相當順利。另外很有趣的是，它可能在初學者-初學者組合下效果最佳，前提是以鍛鍊初學者爲目的。乒乓結對模式下，兩人角色轉換得非常頻繁，使得他們總能一起思考，因此所有的組合都能進行順利（儘管會帶來一些人際關係問題）。
七、分佈式模式
我將以一種“非正式”的結對模式收尾。不過這種配對模式極有可能掌握着未來日益全球化的分佈式世界的關鍵，我說的正是分佈式結對模式。
極限編程始於90年代，當時，遠程工作需要Citrix系統與撥號調制解調器。換言之，你在任何地方都做不了協作編程工作，只能由個人完成。但20年後，託管的硬性要求隨着技術發展而弱化了。你可以用Screen Hero之類的軟件無縫銜接。顯然，就個人而言，協作仍然更有效，但技術已經縮小了很大的差距。另外，人們隨時隨地協作產生的長遠收益是不可否認的。
相信在未來，結對編程模式還需要加入經得起考驗的技術。不過我認爲分佈式模式會變得更加多元化。前面幾種模式隨着時間推移均進行了技術的更新與完善。我認爲不到20年，我們將看到一些頗明智且複雜巧妙的結對編程模式。
原文鏈接：https://stackify.com/pair-programming-styles/
關於作者
Erik是DaedTech的創始人。他是一名程序員、架構師、IT管理顧問、博主和技術專家。
關於EAWorld
微服務，DevOps，元數據，企業架構原創技術分享，EAii（Enterprise Architecture Innovation Institute）企業架構創新研究院旗下官方微信公衆號。
掃描下方二維碼，關注成功後，回覆“普元方法+”，將會獲得熱門課堂免費學習機會！
微信號：EAWorld，長按二維碼關注。
