簡介
結對編程技術是一個非常簡單和直觀的概念，能達到事半功倍的工作效果。但是，人與人之間的合作不是一件簡單的事情——尤其當人們都早已習慣了獨自工作的時候。實施結對編程技術將給軟體項目的開發工作帶來好處，只是這些好處必須經過縝密的思考和計畫才能真正體現出來。而另一方面，兩個有經驗的人可能會發現配對編程里沒有什麼技能的轉移，但是讓他們在不同的抽象層次解決同一個問題會讓他們更快地找到解決方案，而且錯誤更少。
兩個程式設計師具有相同的缺點和盲點的可能性很小，所以當我們採用結對編程的時候會獲得一個強大的解決方案。而這個解決方案恰恰是其它軟體工程方法學中所沒有的。
在我們平時的編程當中，如果遇到一個非常難解決的問題（困難到對該項目產生厭煩的態度），那么你勢必會希望錄求幫助，無論是從信息量龐大的網上，還是從身邊的技術大師那裡，你都會努力去解決（前提是你有對計算機知識的熱愛）。這個時候不妨採用結對編程試一下，其它的不說，可能感覺就不同。
優勢
其實結對編程做起來很簡單也很有趣，找個水平差的不太遠的程式設計師和自己配成一對。只用一台計算機，大家選一個人坐在鍵盤前面負責輸入，另一個人坐在後面口述。兩個人要不斷的交流，頻率不應低於一分鐘一次。整個的設計思想由後面只動口不動手的人主導，而由操鍵盤的人做實現。由於人的思維速度是快於輸入代碼的速度的。那么觀看的人可以有空閒的時間做額外的思考，觀察代碼寫的有沒有問題，結構有沒有問題。
如果程式設計師的經驗積累足夠，是很容易看出存在潛在問題的代碼的，即表面上實現了功能，但實際上是一種糟糕的做法。這在XP(eXtreme Programming 極限編程)中被稱為代碼壞味道，在 Martin Fowler的《重構》一書中有詳細的介紹。兩個有經驗的程式設計師同時在一起工作，看起來好像浪費了一個人的時間：但實際上的效果確實完成了更高質量的代碼。程式編的不那么容易出BUG，而且代碼也寫得更為優雅和緊湊。
關於結對編程，發現了一些新的受益之處。首先，它可以促進參與項目的程式設計師自身的提高，一對程式設計師工作的時候，水平較低的一方會潛移默化地受水平略高的程式設計師影響，學到一些新的東西。而水平高的一方同樣因為不斷地把自己的想法說出來而整理了自己的思路。
其次，一定時間周期地打亂配對，讓參與項目的人員相互轉換位置，使得維護繁雜的文檔變得不那么重要。大家分組打亂後，口頭的交流很容易讓所有人都熟悉每個模組，這樣對於公司也很有好處，項目中萬一有人離開，也不至於影響到整個項目。最後，開發過程變得更為有趣，任何人的交流變得很多，大家關係更為融洽。
另外想補充一點的是，講解XP的書籍上都沒有提到，但是實際上卻存在的一點：結對編程使得程式設計師被迫提高了工作效率。如果單獨工作，在遇到困難的時候，並不是所有人都立刻積極地去解決問題，這時或許會上網和網友聊聊天，看看無關的網站等等。有可能因為工作的打斷，大半天的時間都浪費了。看起來，程式設計師每天都在加班，實際有效工作時間往往還達不到6個小時。而結對編程有一種相互督促的作用，在一邊工作疲憊狀態不好時，另一邊會起一個鼓勵和激發鬥志的作用。
而且兩個人共用一台電腦，略帶私人性質的聊天活動都會很自覺地不去進行了。結果一天下來，新實驗結對編程的程式設計師都會喊累，神經緊繃8個小時的工作不累才怪。
從這個角度看，嚴格限制結對編程的程式設計師不準加班是合理的，實際上，開始每天甚至不必限制8小時工作，每天這樣工作6小時隊項目同樣是非常高效的。
當兩個人不斷的互換角色，以至於最後誰也記不清哪行代碼是誰敲的；團隊內循環的分組以至於分不清到底那個模組該誰負責；反而大家的感覺會不錯。整個項目的代碼是團隊共有，而不再是個人作品了。
成本和收益
一些研究發現程式設計師結對工作與單獨工作相比，會寫出更短的程式，更好的設計，以及更少的缺陷。研究發現缺陷率降低15%到50%，會由於程式設計師的經驗以及任務的複雜度而不同。結對編程比單獨編程相比，通常會考慮更多的設計選項，達成更簡單，更易維護的設計；程式設計師們也會更早地捕捉到設計的缺陷。結對編程與一個程式設計師承擔同一個任務相比工作會完成的更快。結對的程式設計師經常發現當他們一同工作時表面上“不可能”的問題變得容易，或更加快速，或至少有可能解決。
然而，一個2007年的元分析得出結論“結對編程並非一致地有利或有效的”，這是因為是否結對編程選擇以外的許多因素在編程任務的產出上起著很大的最用。元研究發現結對編程往往一定程度地縮短了開發時間，而且對代碼質量產生了正的邊際效益，但是結對編程大大增加了開發人員的工時；也就是說與單獨編程相比花費大大增加了。作者指出有關結對編程的研究遭遇了發表偏倚，有些不利於結對編程的研究要么沒有開展研究，要么沒有投稿，要么沒有被授受發表。他們得出結論“你不可能期待又快又好又便宜。”
雖然編碼通常比一個程式設計師單獨工作更快地完成，但是整體程式編寫時間（程式設計師數目 × 花費的時間）增加了。管理者需要在工作更快的完成以及縮減測試和調試時間和更高的編碼成本之間平衡。這些因素的相對權重在不同的項目、不同的任務之間也不同。對於那些程式設計師沒有完全理解的任務上，程式設計師期待更多的創造性，挑戰，以及 高複雜度，此時使用結對編程最有幫助。在簡單的，程式設計師都完全了解的任務上，結對編程導致生產力的淨下降。
在兩個程式設計師工作時，兩個程式設計師之間傳遞著知識。他們分享關於系統細節的知識，並且互相學習編程技巧。新的員工很快地獲得團隊的習慣，並學習到系統的細節。“混雜結對編程”，即每個程式設計師輪流與團隊中的所有其他程式設計師結對編程，而不是僅與某個程式設計師編程，使得系統的知識在整個團隊中傳播，減少了程式設計師離開團隊帶來的風險。
結對編程通常會帶來紀律和時間管理的提升。程式設計師在與結對的夥伴一同工作時，不太會忘記編寫單元測試，花時間上網或處理個人電子郵件，或偷工減料。結對的夥伴“讓他們保持誠信”。人們更不願意打斷兩個結對編程的人，而單獨工作的人卻容易被打斷。
其他的收益據報告包括提高士氣以及在代碼正確性上更大的信心。
變體
遠程結對編程
遠程結對編程，也稱作虛擬結對編程或分散式結對編程，是指兩個程式設計師不在同一地點，通過協同編輯器，共享桌面，或遠程結對編程的IDE外掛程式進行的結對編程。遠程結對編程引入了一些在面對面的結對編程中不存在的困難，例如協作的額外時延，更多的依賴“重量級”的任務跟蹤工具，而不是“輕量級”的索引卡片，以及沒有口頭交流導致的在類似誰“控制鍵盤”問題上的混亂和衝突。
許多工具，例如Eclipse有外掛程式支持遠程結對。有些團隊嘗試使用VNC和RealVNC，每個程式設計師使用他們自己的計算機。其他人使用基於文本的GNU Screen的多顯示模式。蘋果公司的Mac OS X包含內建的螢幕共享套用。
桌球結對編程
在桌球結對編程中，觀察者編寫失敗的測試用例，駕駛者修改代碼以通過該用例，觀察者編寫新的單元測試用例，等等。這個循環持續到觀察者不能寫出失敗的測試用例。但是這種方法比估計的計畫要花更多的時間。
