為什麼結對程式設計并不那麼受歡迎？

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

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

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

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

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

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

如果你的團隊在嘗試結對程式設計上仍保持謹慎，好消息是将結對程式設計融入到企業文化當中已經有一些公開的案例。其中一個例子是menlo innovations公司，他們要求所有的開發人員每天都要進行結對程式設計。結對程式設計是其招募員工的條件之一。雖然這并不一定對所有人都是最優的方案，至少能起到一定的作用。

讓開發人員能夠結對程式設計的一個關鍵因素是較高的安全系數。總的來說，絕大多數開發人員會擔心被發現他們其實比他們所表現的要缺乏競争力。有人将其看做是負擔症候群的執行個體。負擔症候群通常會出現如下症狀：自己對自己的能力産生懷疑，而又極力說服其他人自己的确擁有這種能力。

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

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

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

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

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

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

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

當團隊就某項新的技術做出嘗試時，務必從團隊成員處擷取匿名回報，以了解包括結對程式設計在内的這類嘗試效果如何。試着讓團隊成員自行發現如何才能在與不同的夥伴合作、結對時更加自信。對于新的技術實踐，總是需要經過多次嘗試之後，團隊成員才能夠得心應手。

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

其目的是讓一個或多個開發人員發現結對程式設計其中的價值。無論結對程式設計的嘗試結果如何，團隊上司人/經理都應該對團隊持支援态度，繼續鼓勵每個團隊成員的個人發展。

對于安全感比較低的團隊上司者，更加明智的選擇可能是為團隊成員播放一段結對程式設計的視訊，或者鼓勵他們閱讀結對程式設計有關的書籍。laurie williams與robert kessler合著了《pair programming illuminated》一書。書中分享了幾種不同類型的結對程式設計的案例，包括哪些案例可行哪些不可行。另外一個選擇是利用網際網路。在網際網路上快速檢索可以找到大批量的結對程式設計有關的教程、視訊和文章。

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

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