專業程式設計領域總是產生一些相當激烈的爭論。例如關於是否以及怎樣對**作注釋。我們很難平息這些爭論，因為科學地論證專業程式設計是有難度的。我們不可能真的要求大公司用乙個對照組與乙個實驗組兩次構建同乙個軟體。因此很多時候我們的依據是傳聞或個人意見，極缺經驗資料。因此，相比是否該選擇結對程式設計，今天我更想談談結對程式設計的模式。
我先前曾從業務角度談論過結對程式設計的好處，現在我以同樣的方式來介紹今天這篇文章。你能從中獲益，但你必須評估它對你是否有意義。要想做好評估，你就應該了解不同的結對程式設計模式以及它們都是如何運作的。
沒錯，結對程式設計並非只是把兩個人扔一起、讓他們瘋狂撒歡。多年以來，從業者開發了一些應用於不同情況的技術，通過實踐與實驗，他們對這些技術作了提高與完善。
一、熟練程度不同結對程式設計模式的影響
看實際方案之前，讓我們先繞個小彎看看不同開發人員的技術水平。儘管我們看似特別傾向於細緻地區分不同技術水平，但我覺得實際只存在兩種開發人員技術水平：初學者和專家。我懂，我懂，你們一定覺得這種分法太草率了，但這樣確實可以把複雜性降到最低，且能很好地解釋不同結對模式。根據我們這兩種技術水平，能得出以下三種結對組合：
請注意，我這裡談及的專業技術，是背景的一部分，而不僅僅是一般的行業經驗。技術的積累、對**庫的熟悉程度、甚至還有專業領域知識在這都很重要。我有兩個電腦科學學位，對幾種物件導向的程式語言也有數年經驗，但如果我哪天加入你的go語言團隊，你可以妥妥地把我放在初學者陣營直到我找到自己的定位。
每種結對模式有它的優缺點，然而有時候命運可能迫使你根據哪個人有空來做出選擇，到時候對不同結對模式的了解會助你更有效率。另外，值得一提的是，初學者-初學者的組合可為二者提供很多的學習機會，但有風險。因此，這種組合的適用性更多地取決於你對風險而非結對模式本身的傾向。
二、非結構化結對模式
設想一下結對程式設計誕生時的情況，李四走到張三的格仔間辦公室，說：「嗨，我們一起用fortran語言工作吧。」好吧，這麼個小故事也許不足為信，不過想象一下它會怎麼發展吧。李四和張三習慣把程式設計作為獨自的工作，某天卻決定把他們的智慧型結合在一起。他們不一定知道任何程式設計協作的技巧，所以他們臨時結夥，試著互相幫助。
這是我要列舉的第一種協作示例。如果覺得很荒唐，那你要錯過這堂課了。知道一些技巧可以嘗試當然很有幫助，但不要麻痺了你的分析能力。如果你想起步，試錯(測試與出錯)會有很大幫助。就像下面的結對技巧通過試錯而不斷進步，你自己也需要這樣。
但也要知道結對的組成中也存在著限制。它需要兩個夠格的頭腦和單單一台計算機，所以當你在程式設計而你的夥伴在檢查她的郵件是不行的。你可以視情況用些不同的溝通技巧，如「鍵盤用乙個還是兩個?」、「誰來打**?在什麼時候?」
三、駕駛員-領航員模式
就已建立的模式而言，我們先來看一下駕駛員-領航員模式。理論上這可構成最成熟的模式。
它的名字源於兩個人可能作汽車旅行穿越未知區域的場景，駕駛員的注意力集中在機械方面，包括操控油門和剎車，調轉車輪還有提防障礙與其他車輛。與此同時，領航員則考慮更巨集觀的問題。還要開多久才能下高速?手機是否能及時收到任何突發交通堵塞的提示?
把這對關係的比喻應用於程式設計，那麼駕駛員就負責寫**，瀏覽檔案，還有基礎實現方法。領航員則著眼更長遠的考慮並且檢查錯誤。這方法適合這種架構嗎?我們有沒有可能另闢蹊徑重寫乙個實現方法?我們是否困在死胡同裡了?
如果二者都是可互換角色的專家，那麼駕駛員-領航員模式會很理想，對於專家與新手的組合來說也不錯。這個模式在專家做領航員時最容易起效，因為讓菜鳥來當領航員，他可能只會被動地乾坐著而讓專家分飾兩角。
四、後座領航員模式
接下來要講的結對程式設計模式是後座領航員模式。這方案看起來像是駕駛員-領航員模式，但領航員接管了更多具體策略的工作(讓人聯想到後座駕駛員)。
和駕駛員-領航員模式一樣，駕駛員在鍵盤前坐著，執行諸如寫**的工作。但不像駕駛員-領航員模式，後座領航員下達的是更細緻的指示。這意味著她可能告訴駕駛員什麼時候建立乙個方法或開啟乙個新的檔案。她還會告訴他應該如何為乙個測試或變數命名。
這種模式在以初學者為駕駛員的初學者-專家組合中發揮得最好。初學者在按照專家指示做事的過程中得到學習。
五、嚮導模式
另一種非常適合專家-初學者組合的模式是嚮導模式。同樣，駕駛的比喻依然適用。
設想去某地度假並在當地旅行。駕駛員登上客車或巴士，開始駕駛，然後告訴你他正在做的每件事情和你所看到的每樣事物。你的地位就很被動。
嚮導模式程式設計模式也是這樣。駕駛員做戰略與策略上的思考，同時寫**。當她這麼做時，她告訴「遊客」她正在做什麼。遊客很少介入。
這在專家駕駛員與菜鳥遊客組合上很有效，尤其是菜鳥一無所知的情況下。但如果角色互換，它其實也同樣有效。初學者可以在專家的觀察下探索解決問題，專家則提供反饋與糾正，如此反覆。
六、桌球結對模式
要認真完成結對程式設計模式的學習，你還得了解桌球結對模式。這種模式有個不同於其他模式的有趣因素。
為了便於理解，把結對程式設計看成一項極限程式設計運動，這些人深愛著結對程式設計和其他具體應用，如單元測試。因此當你遇到乙個極限程式設計者，你可以穩妥地認定她喜歡結對也喜歡實踐測試驅動開發(tdd)。
這個步調很簡單，前乙個人寫乙個失敗測試而後乙個人設法通過。接著後乙個人寫失敗測試讓前乙個人設法通過。如此來回往復，有點像桌球。
這種模式在兩個專家的組合時進行得格外完美，初學者-專家組合也進行得相當順利。另外很有趣的是，它可能在初學者-初學者組合下效果最佳，前提是以鍛鍊初學者為目的。桌球結對模式下，兩人角色轉換得非常頻繁，使得他們總能一起思考，因此所有的組合都能進行順利(儘管會帶來一些人際關係問題)。
七、分布式模式
我將以一種「非正式」的結對模式收尾。不過這種配對模式極有可能掌握著未來日益全球化的分布式世界的關鍵，我說的正是分布式結對模式。
極限程式設計始於90年代，當時，遠端工作需要citrix系統與撥號數據機。換言之，你在任何地方都做不了協作程式設計工作，只能由個人完成。但20年後，託管的硬性要求隨著技術發展而弱化了。你可以用screen hero之類的軟體無縫銜接。顯然，就個人而言，協作仍然更有效，但技術已經縮小了很大的差距。另外，人們隨時隨地協作產生的長遠收益是不可否認的。
相信在未來，結對程式設計模式還需要加入經得起考驗的技術。不過我認為分布式模式會變得更加多元化。前面幾種模式隨著時間推移均進行了技術的更新與完善。我認為不到20年，我們將看到一些頗明智且複雜巧妙的結對程式設計模式。
六種單列模式
確保某乙個類只有乙個例項.1 餓漢式單列 public class singleone 構造方法私有 禁止建立 private singleone 2 懶漢式單列 public class singletwo 同步方法 每次呼叫都同步 消耗資源 public static synchronized ...
jBPM的tasknode的六種模式
jbpm的tasknode的六種模式 last 預設值。當最後乙個任務完成時 signal 當 task node 沒有建立任務時，直接 signal。last wait 當最後乙個任務完成時 signal 當 task node 沒有建立任務時等待。first 當第乙個任務完成時 signal 當...
CODESYS六種程式語言的特點
codesys共支援六中不同的程式語言，很多學者在學習的過程中常會問乙個問題，哪種程式語言最好？其實本人覺得沒有哪種程式語言是絕對的好或不好，不同的工程應用具有不同的最佳程式設計方式，每種程式語言都具有其不同的特點，可根據實際工程應用的需求選用合適的程式語言，下面簡單介紹下codesys的6種不同語...