過去十多年中，筆者曾經與上百個開發(fā)團隊共同合作，這些團隊具有一個共同的特點就是：他們通常不會采用結對編程作為軟件交付的技術。其中一些團隊會討論結對編程并且認同這種理念，不過由于某種（些）原因，他們目前仍未采用結對編程。那么接下來的問題就是，是什么原因導致他們不采用結對編程呢？在我個人的經驗當中，采用結對編程和協(xié)作仍有許多障礙。許多團隊合作（cooperate）的很好，但實際上并不是協(xié)作（collaborate）。因為協(xié)作基于信任，它是結對編程的關鍵環(huán)節(jié)之一。

結對編程是軟件開發(fā)過程中所使用的一種技術，兩名程序開發(fā)人員共享同一臺工作站，其中一名開發(fā)人員被稱為駕駛員（Driver），另一位被稱為領航員（Navigator）或觀察員（Observer）。兩人輪流使用同同一個鍵盤編寫代碼和測試案例。兩個開發(fā)人員輪流使用鍵盤可以讓每個開發(fā)人員都有機會思考設計和相應的實現。兩人還能夠從相互的思想交流中受益，通常能寫出更加高效的代碼。

結對編程的概念相當簡單明了，而且在90年代后期，極限編程（XP）的早期就已經開始有實際的應用。不過在我個人的經歷中，它仍是使用最少的極限編程技術之一。敏捷實踐和極限編程的流行讓這一問題得以回避。據我的了解，結對編程仍存在許多障礙。

我們首先從組織層級開始分析。許多經理覺得開發(fā)者結對編程時，他們付出了兩個開發(fā)人員的代價卻只得到了一個開發(fā)人員的生產力。在團隊剛剛開始結對編程時的確如此，不過只需經過很短的時間，結對就會以更快的速度交付更多的功能，而且經常只需要更少的代碼，而且質量也會有一定的提升。結對編程能夠幫助在進行測試之前就解決掉代碼中的問題，遺留到生產環(huán)境中的會更少。

組織級的挑戰(zhàn)并未到此為止。還有一些關于實際環(huán)境方面的考慮。如今，開發(fā)人員通常會占據一個受限的工位空間。結對則需要至少6英尺大的開放式座位空間，以便兩人可以并肩坐在一起。有些組織還缺乏適用于結對編程的硬件，例如無線鍵盤，無線鼠標，以及至少21寸的顯示器。對于顯示器來說，則是越大越好。

除了硬件設備之外，組織級的挑戰(zhàn)還存在于對開發(fā)人員的認可、加薪和晉升的機制。組織對員工進行排名會嚴重限制開發(fā)人員有效地學習結對編程的可能性。許多情況下，開發(fā)人員希望被視為超級英雄，以借此提升其在同事之中的級別。另外一個阻礙是績效評估。很少有公司會將團隊合作視為一項有價值的技能，更多的是尋找能夠拯救公司于危難之中的“超級英雄”。此外，一直處于在戰(zhàn)術層面滅火模式的組織難以體會在結對編程過程中開發(fā)人員進行的技術和專業(yè)領域知識分享所帶來的價值。

如果你的團隊在嘗試結對編程上仍保持謹慎，好消息是將結對編程融入到金喜正規(guī)買球當中已經有一些公開的案例。其中一個例子是Menlo Innovations公司，他們要求所有的開發(fā)人員每天都要進行結對編程。結對編程是其招募員工的條件之一。雖然這并不一定對所有人都是最優(yōu)的方案，至少能起到一定的作用。

讓開發(fā)人員能夠結對編程的一個關鍵因素是較高的安全系數。總的來說，絕大多數開發(fā)人員會擔心被發(fā)現他們其實比他們所表現的要缺乏競爭力。有人將其看做是負擔癥候群的實例。負擔癥候群通常會出現如下癥狀：自己對自己的能力產生懷疑，而又極力說服其他人自己的確擁有這種能力。

一部分人會認為代碼審查已經足夠并且已經實際運轉多年。代碼審查的問題在于其發(fā)生在代碼已經完成，而且常常是已經經過測試并準備發(fā)布時。如果發(fā)現問題，就會浪費許多編碼時間，而且還不得不重新返工并測試這個問題，之后再次經過審查。不幸的是，這在代碼審查中時常發(fā)生。更有甚者，開發(fā)人員會陷入哪一種技術最佳的爭辯之中。這種情形下，要么最資深的人強制開發(fā)人員做出修改要么房間中最大的聲音獲勝。這兩種情形都會破壞團隊之中的信任感。

當要求開發(fā)人員嘗試結對編程時，他們可能會有頗有微詞。譬如：‘如果我自己做速度會更快’或者‘與同事結對編程沒有任何意義，因為我不會從他們身上學到什么東西’或者僅僅是‘我已經嘗試過了，但并沒發(fā)現有什么作用’。盡管這些爭辯可能是對的，但也可能只是他們感覺在有另一個人在場的情況下編程不安全。

最根本的挑戰(zhàn)在于如何創(chuàng)建一個能夠讓開發(fā)人員覺得可以安全地學習、犯錯、快速失敗、持續(xù)提升技能的環(huán)境。由于失敗會遭受懲罰，一些開發(fā)人員會害怕失敗。會對失敗員工做出懲罰的組織不太可能鼓勵員工嘗試和成長。

通常，一個團隊中的成員會被聚集在一起，而不會作為個體互相了解。如果你的團隊還不會在一起分享社交時間，那么這可能是一個最佳起始點。帶領團隊郊游、午餐、共享歡樂時光或者他們希望一起體驗的其他活動。鼓勵他們一起在辦公室或外出午餐。宴請員工午餐或者郊游可以打消他們對開銷的顧慮。向公司申請對此類活動的資助可能需要一點勇氣，必要的話，團隊領導要做好自己為此買單的準備。

為團隊成員學習創(chuàng)造一個安全的環(huán)境可能會成為許多組織的挑戰(zhàn)。一旦創(chuàng)造了一個適合于結對編程的辦公環(huán)境，六英尺或更長的桌子和兩張舒適的椅子，那么接下來就需要合適的顯示器、鍵盤和鼠標。如果是第一次設置結對編程工作站，可以考慮使用一個只有白板的小的會議室空間。在實際編寫代碼之前，開發(fā)者喜歡在白板上草擬程序的設計和邏輯。現在你已經擁有了一個適用于結對編程的實際空間。

下一個挑戰(zhàn)則是為開發(fā)人員提供一個便于結對編程的機會。例如，請一名資深開發(fā)人員與一名初級開發(fā)人員或團隊中的新員工結對完成一個故事。在試驗當中，每個個體都應該有機會嘗試結對編程練習的機會。強制開發(fā)人員結對編程通常不會帶來預期的收益。

我曾經用過并且有良好效果的另外一個技巧是雇傭一個有良好聲譽的顧問作為強力開發(fā)人員。合約期限可以很短，兩周時間就能夠產生顯著的影響。讓開發(fā)人員知曉該顧問可以與他們進行1對1的代碼會話，并建議他們參加一個小時的時間。可以建議他們用當前所分配的任務進行嘗試或者讓顧問分享一些練習案例。讓團隊與備受尊敬的顧問一起工作的另外一個好處是該顧問可能還會鼓勵使用其他優(yōu)良的技術實踐，如TDD。

當團隊就某項新的技術做出嘗試時，務必從團隊成員處獲取匿名反饋，以了解包括結對編程在內的這類嘗試效果如何。試著讓團隊成員自行發(fā)現如何才能在與不同的伙伴合作、結對時更加自信。對于新的技術實踐，總是需要經過多次嘗試之后，團隊成員才能夠得心應手。

有多種方式可以在工作之余鼓勵結對編程，這時團隊成員不會對他們在團隊中的地位有太多顧慮。代碼訓練營和代碼道場可以提供一個寬松的環(huán)境，在這里絕大多數人都是學習者，同時也能夠分享他們的經驗。敏銳的觀察者可以識別出團隊中最有可能嘗試新技術的成員。與該成員一對一對話，鼓勵他們建立自己的專業(yè)技能并為他們提供這樣的機會。

其目的是讓一個或多個開發(fā)人員發(fā)現結對編程其中的價值。無論結對編程的嘗試結果如何，團隊領導人/經理都應該對團隊持支持態(tài)度，繼續(xù)鼓勵每個團隊成員的個人發(fā)展。

對于安全感比較低的團隊領導者，更加明智的選擇可能是為團隊成員播放一段結對編程的視頻，或者鼓勵他們閱讀結對編程有關的書籍。Laurie Williams與Robert Kessler合著了《Pair Programming Illuminated》一書。書中分享了幾種不同類型的結對編程的案例，包括哪些案例可行哪些不可行。另外一個選擇是利用互聯網。在互聯網上快速檢索可以找到大批量的結對編程有關的教程、視頻和文章。

如果在鼓勵結對編程這方面的嘗試不太成功或者正在為團隊尋找其他的協(xié)作機會，可以考慮在團隊中開展Mobbing會議。Mob編程正在獲得越來越多的組織的青睞。Mobbing的其中一個附加好處就是通過輪流在唯一的共享鍵盤上輸入，每個人都能夠參與到設計和編碼當中。Mob編程可以幫助在團隊中建立更好的共享責任觀念并且?guī)椭鲞M團隊成員之間的關系和信任。對于任何一項新的技術，團隊都需要經過實踐才能夠逐漸適應。最后，隨著團隊成員之間彼此開始逐漸互相信任，他們就會更愿意嘗試其他的新技術，這也就能夠為他們開創(chuàng)一種更好的合作方式。

一旦團隊開始接受結對編程，要不斷鼓勵他們嘗試其他的技術實踐。不論成功和失敗，都要不吝贊美，因為這都是寶貴的學習機會。

本文來源：