結對程式設計簡介

　結對程式設計簡介

　　一個由聰明能幹的開發者組成的敏捷團隊正在努力完成交付。他們遇到了一些意料之外的缺陷，正在努力修復生產環境中發現的缺陷；前端開發的工作量比後端開發更大，因此當前端開發者掙扎著試圖跟上進度時，後端開發者反而處於無所事事的狀態。可能他們需要更新控制器系統，但是Brian是唯一一個能夠看懂控制器程式碼的人，不幸的是他現在正在忙其他事情。這個場景是不是很熟悉？結對程式設計可以有效地解決這些問題並給這個煎熬中的團隊帶來更多好處。那麼為什麼很多團隊不進行結對程式設計呢？

　　在《Pair Programming Illuminated》一書中，Laurie Williams和Robert Kessler曾斷言：

　　我們發現很多人不願意採用結對程式設計——這需要改變現有習慣並且具備更強的溝通和協作能力……我們知道，如果被強迫採用結對程式設計，有些人寧可選擇辭職。

　　讓團隊適應結對程式設計是一件很棘手的事情，那怎麼做才能讓你的團隊更容易接受結對程式設計呢？

　　問題到底出在哪裡？

　　首先我們來思考一下為什麼結對程式設計很難落實，以下是一些原因。

　　1. 對於團隊來說這是個很大的變化

　　很少有工作實踐能像結對程式設計這樣對團隊造成巨大影響。在傳統的工作中，開發者會“進入狀態”：帶上耳機開啟音樂；手邊就是咖啡因飲料和零食。大部分開發者都不能適應在工作中和同事進行大量溝通，他們需要一段時間來適應對話狀態！

　　2. 精神高度集中

　　這是結對程式設計有效的祕籍之一：專注、專注、專注！如果你正在結對程式設計，那就不可能檢視Facebook、瀏覽網頁或者回復收件箱中剛收到的郵件。

　　3. 疲憊

　　結對程式設計需要的專注和緊張程度高於大部分人的日常工作強度。結對程式設計會把你稍微推離舒適區並鍛鍊你的專注能力。但是無論你多麼擅長結對程式設計，都會到達極限。Kent Beck寫道“絕大多數程式設計師每天的結對時間不能超過五或者六個小時。”

　　4. 大部分成員都沒有完全具備所需要的軟技能

　　人類不是生來就有同理心和超強的社交技能的。如果你在工作中和同事交流很少，那你在這方面的技能可能就會弱一些。想象一下，和一個缺乏社交技能的人緊密合作一整天是什麼感覺。或者，想象一下作為新手和一個不耐煩的老手一起程式設計的感覺。結對程式設計的兩方都需要很高的耐心和同理心。

　　5. 所有的改變都很困難

　　所有的變更管理專家都會告訴你——要求他人改變做事的方式會立刻激發恐懼反應，人們試圖理解改變對他們的影響。

　　既然如此艱難，為什麼我們還要改變呢？

　　接下來，我們會討論到底是什麼支撐你克服這些障礙。結對程式設計有很多好處，我們來看看你能獲得什麼回報。

• 更高質量的程式碼

  如果每行程式碼在編寫的同時都在被審查，程式碼質量就會急劇提高。由於審查者完全參與到程式碼的編寫過程中，因此程式碼審查的質量也會提升。類似Alistair Cockburn和Laurie Williams所做的研究，其他研究也對比了結對程式設計和單人程式設計產生的程式碼，發現結對程式設計產生的程式碼缺陷更少，設計更良好。在Cockburn和Williams的研究中，結對程式設計產生的程式“普遍比單人程式設計產生的程式短20%，這表明前者的程式碼更優雅、可維護性更高。”

• 更高的“巴士指數”

  “巴士指數”是一種表示團隊的知識、經驗和程式碼擁有權共享程度的方法——如果有人離開（也就是被巴士撞了），我們中有多少人可以頂替他的位置？如果你的團隊巴士指數是1，那就意味著團隊中某人是不可或缺的——如果他突然離開，你的專案就有大麻煩了。結對程式設計可以讓你的巴士指數等於團隊成員數——每個人都可以在任何時間接手任何任務。

• 更強的團隊凝聚力

  和同事整天在一起工作可以讓你更好地瞭解他們，從而更加理解他們，增強團隊凝聚力。

• 更高的工作滿意度

  大多數程式設計師最後會發現和同事分擔程式設計任務可以讓自己更輕鬆——當他們習慣之後。他們不再需要自己承擔所有責任，並且可以互相幫助。

• 更高的效率

  是的，沒錯，結對程式設計比單人程式設計的效率更高。這確實有點違反直覺，兩個人寫一份程式碼怎麼會比兩個人分別寫兩份程式碼更快呢？

  1. 當你和其他人一起討論的時候，可以更快地解決問題。隊友會幫助你把精力聚焦在問題上，並且能幫你搞定一些你自己不確定或者不熟悉的領域的問題。你花費在常見問題、研究和查詢程式碼語法上的時間會減少。

  2. 更少的缺陷意味著更多時間用在建立新特性而不是修復bug上！因此，效率更高。在上面提到的Williams和Cockburn的研究中，結對程式設計花費的人時只增加了大約15%，遠小於從修復bug上節約的時間（bug也減少了15%）。因為在程式碼編寫完成之後修復bug需要花費更多的時間，因此編寫同樣程式碼，結對程式設計的總時間更少。

• 更容易維護的程式碼

  當兩個人一起程式設計時，他們需要在方法、資料結構甚至是變數和函式名上達成一致。這會減少其中一方隨意編寫程式碼的可能性。結對程式設計者也更有可能選擇更加標準的語法、格式以及類似TDD這樣的最佳實踐。

• 更有助於成員發展

  結對程式設計是軟體開發中學習新技能最快的方法之一。除了語言和技術，結對程式設計者還會共享很多其他技能，從解決問題的思路、演算法到鍵盤快捷鍵和除錯技巧。沒錯，你可以通過閱讀他人的程式碼來學習他們解決問題的方法，但是和他們一起工作可以讓你更加清楚他們的思考過程。

• 更高的團隊靈活性

  能讓人們快速地掌握技術和程式設計領域意味著他們可以以最小的代價從一個團隊轉移到另一個團隊。這種靈活性對所有人都有好處。如果一個專案突然需要外援，負責人可以從其他團隊“借”資源並讓資源快速發揮作用。類似地，如果開發者想學習一些新東西，或者想改變工作節奏，可以申請轉移到其他團隊。團隊可以以最小的損失來滿足這些申請。

• 更少的會議

  如果團隊成員整天都在和其他人溝通，資訊就可以快速流動，因此很少需要用會議來討論事情。這對於大部分開發者來說都極具吸引力，比起坐在會議室討論，他們更喜歡實際操作！

　　讀到這裡，希望你已經充分意識到結對程式設計的價值。當你和其他人討論結對程式設計的時候，可以直接引用這個列表中的內容。一定要把這個列表擺在最顯眼的位置，遇到困難的時候就提醒自己回報是什麼。

　　所以，如何進行結對程式設計？

　　下面我會介紹一些減輕痛苦的方法，能夠幫助你更好地推行結對程式設計。當你向開發者們推行新工具或者新技術的時候，要根據實際情況選擇合適的方法，結對程式設計也一樣。首先我們來看看Gina Green和Alan Hevner的研究。

　　Green和Hevner研究了為什麼優秀的程式設計工具和技術經常會被程式設計師拒絕。調查了企業軟體的開發者之後，他們總結出三條推行新技術或者新工具的準則：

1. 讓他們自己選擇何時使用

   開發者希望能夠自由決定結對程式設計的時間。千萬*不要*命令或者強制他們結對程式設計。如果你這樣做，他們會很不高興、不爽、不理睬你，甚至會反抗你。結對程式設計是優秀軟體開發者的思想結晶，並不是源於專案負責人或者流程控制專家。成千上萬的程式設計師在看到結對程式設計的好處之後會自願地接受它，這是唯一一種真正可行的結對程式設計推行方式。

2. 指導他們正確地進行結對程式設計

   建立清晰明確的結對程式設計標準。結對程式設計並不是兩個人坐在一起，一個人編寫程式碼並偶爾問另一個人問題。結對程式設計的意思是兩個人要非常專注於同一段程式碼或者同一段思想，同時只有一個人打字。你需要向團隊成員介紹如何正確進行結對程式設計，比如：

   • 讓稍差一些的隊友“主導”程式設計，即使他們需要很多指導。
   • 共享控制權——兩個人都能控制鍵盤和程式設計。
   • 意見出現分歧的時候要有禮貌地討論。

3. 鼓勵他們（尤其是作為他們的領導！）

   無論你想做什麼改變，都需要清楚地表達出來，並且要不斷重複。即使你感覺自己像臺壞掉的錄音機，也必須不斷重複直到完成改變。因此，要明確地表達出你想讓大家進行結對程式設計（同時不要把它變成命令）。如果你是領導那就更有效了，只要不斷重複，開發者一定會聽進去。

　　記住這三條準則之後，我們來看一些推行結對程式設計的方法。

　　方法一）細胞分裂

　　這種方法適用於你已經擁有，或者可以招聘到經驗豐富並且非常熱情的結對程式設計程式設計師。我們叫他們結對專家。你至少需要2~3人來推行結對程式設計。具體方法如下：

1. 組建一個隊伍，一半是結對專家，一半是結對新手（團隊中沒有結對程式設計經驗並且願意參與的人）
2. 最初，所有的程式碼必須由一個結對專家和一個結對新手結對完成。需要頻繁更換結對目標。
3. 當新手開始適應的時候，你可以放寬專家-新手結對這個要求，但是至少要保證團隊穩定發展三個月，或者直到結對新手都“轉換”為結對專家。這個過程至少需要三個月，一定要有耐心。如果你很快就停止，那新手的經驗無法牢固掌握。
4. 現在你有兩倍的結對專家了。如果你還有許多需要轉換的結對新手，可以把團隊一分為二並加入結對新手組成新團隊。確保在每個團隊中專家的數量都大於等於新手的數量，然後繼續執行步驟2。

　　這個過程開始很慢，但是會呈指數增長。從一個團隊開始，到第一年底你就會擁有八個團隊，到第十五個月就會擁有十六個團隊。到那時，你就很容易在團隊中推行其他技術實踐，比如測試驅動開發和持續整合。這些技能會快速傳播到整個團隊，因為大家都會對彼此負責。

　　注意：頻繁更換結對目標也被稱為“無序結對”。這樣的好處是知識可以在整個團隊中傳播。此外，這樣做也可以避免讓兩個人之間建立太深的感情，從而難以和其他人結對。Kent Beck喜歡每隔幾個小時換一次結對物件，但是一天一次就足夠了。門羅創新公司會每週更換一次結對物件。

　　方法二）從零開始

　　如果你沒有任何經驗豐富的結對程式設計程式設計師，那就只能從零開始了。但是你還是可以遵循一個具體的方法。下面是Laurie Williams等人在《Pair Programming Illuminated》中推薦的方法。

　　第一步是從團隊中找出一個聲望高並且願意協助你進行改變的開發者。選擇一些候選人並向他們解釋你想做什麼以及為什麼要這麼做。記住你的好處列表（上文提到過）。如果他們不能做出決定，可以讓他們參考一下列表中的好處。如果他們拒絕幫助你，那也要讓他們保持開放的心態，不要變成你的敵人，然後詢問下一個候選人。

　　當你找到認同你的開發者之後——我們叫他/她“結對支持者”——就可以進入下一步了。在這個階段，結對支持者開始逐漸向組織中的其他人介紹結對程式設計的思想。最好的方式是向其他程式設計師提供幫助，協助他們完成工作或者進行一對一幫助。這樣，結對支持者就可以不動聲色地和其他程式設計師建立起結對關係。如果這種關係進展順利，結對支持者就可以和隊友討論結對程式設計及其好處，並評估隊友對於結對程式設計的態度。這一階段的目標是發現組織內和你想法相同的人。

　　當你有一批可以接受結對程式設計的人之後，下一步就是和所有人進行公開的討論。列出一個暫時的自願性質的結對程式設計計劃——包括最初有多少對開發者和嘗試多長時間。因為需要一段時間來適應，所以最好嘗試三個月或者更久。讓大家公開討論他們對於結對程式設計的疑慮，並探討如何解決他們的問題。和他們討論評價標準，什麼樣的結果會讓大家相信結對程式設計是一件值得長期堅持的事情？討論如何收集資料從而可以驗證結果是否符合標準。最後詢問有多少人願意參與。如果可能的話可以加入物質獎勵，從而讓結對程式設計者在一個理想的新專案上開始工作。

　　其他建議

　　除了推行結對程式設計，還有一些需要思考的內容：

• 並不是所有人都適合結對程式設計

  事實是組織中有些人可能永遠不會加入。你可以選擇：

• 如果他們願意的話指導他們。

  一個優秀的教練可以幫助團隊中的成員處理恐懼和困難，幫助他們找到解決方法。

• 給他們一些不需要結對程式設計的任務。

  或許你可以給他們分配一些單人程式設計也可以完成的任務。

• 接受損失

  做好心裡準備，有些人會選擇離開。願意接受結對的新人可以代替他。

• 把結對程式設計加入招聘流程

  在第一次面試候選人的時候和他進行一個簡單的結對程式設計練習是一個好辦法。讓專家觀察候選人，判斷他們是否具備和隊友溝通的能力。通過測試的候選人還需要和多個隊友進行一整天的結對程式設計，然後再決定是否聘用。

• 確保有足夠的獎賞

  如果你獎賞單人行為和單人成就，那其實會影響結對程式設計模型，並鼓勵人們繼續單人工作。因此，必須重構你的獎勵體系，關注團隊而不是個人。

• 你可能需要重新排列辦公桌

  結對程式設計需要一個長條辦公桌，讓他們挨著坐並且有足夠的活動空間。每個結對辦公桌需要放置兩個大顯示器、兩個鍵盤、兩個滑鼠和一臺電腦。儘量避免築牆，每個人都需要說話，他們不需要安靜。合作的嗡嗡聲將會給你的團隊帶來活力。

• 提供娛樂設施並允許休息

  很多人都發現，在結對間隙放鬆幾分鐘非常有幫助。乒乓球桌是個不錯的選擇，可以實現短暫的激烈運動，並且非常有趣。

• 牢記變化管理曲線

  無論要做出什麼改變，都需要準備好面對暫時的效能下降。如果大家都知道你已做好心理準備，那曲線就會緩和一些。

• 調整組織的整體期望

  當你慶祝結對程式設計帶來的好處時，別忘了讓組織中其他人學會尊重結對程式設計並且不要期望電子郵件能夠得到立刻回覆。可以使用其他方法來實現外界和你的團隊之間的資訊流通，比如使用站立會議時間，或者指派一個團隊領導/敏捷教練來收取外界的請求並在適當的時間傳達給團隊成員。

　　分散式團隊

　　工作地點不一致的團隊怎麼辦呢？他們能獲得結對程式設計的好處嗎？當然可以，只要他們願意付出一些額外的努力。有許多工具可以幫助程式設計師共享螢幕和音/視訊，從而建立一個虛擬的結對環境。可能需要一些嘗試來判斷哪些工具最適合你的技術棧。雖然視訊是可選的，但是我很推薦視訊——獲得肢體語言和表情反饋可以極大地幫助你理解隊友的狀態。比如說，他保持沉默的原因是因為感到疑惑嗎？他在思考嗎？還是他起身去休息了呢？經驗豐富的遠端結對程式設計者Joe Moore的部落格是學習遠端結對的好地方。讓團隊短期共同工作也是一個好辦法——比如一次或者兩次衝刺——這可以讓他們在遠端結對之前適應結對程式設計。

　　結論

　　結對程式設計對於所有軟體開發公司來說都極具價值。它可以顯著提高質量和速度，甚至可以提高開發者的工作滿意度。為了獲得這些價值，需要非常謹慎小心地把結對程式設計引入到你的團隊中。避免命令和強制要求，要不斷鼓勵和獎勵他們。這項強大的技能會在日復一日的練習中逐漸顯現出威力，讓你的團隊慢慢發現它的作用並達成共識。最後，別忘了，結對程式設計不適合所有人，所以要想好如何迴應那些拒絕結對程式設計的團隊成員。

　　作者介紹

　　　Melinda Stelzer Jacobson是一名敏捷教練，堅信生產力和成功源自快樂的成員和重視信任、尊重和溝通的團隊。她的信念源自15年的軟體開發經驗，包括電信、銀行、科學裝置、網站和網際網路程式。Melinda住在舊金山，曾獲得敏捷專家認證、敏捷開發者認證、ICAgile專業敏捷教練認證、DAD黃帶和創新遊戲合作架構師認證。在業餘時間她會收養可愛的流浪兔，這樣它們就不會被安樂死。

　　英文原文：Introducing Pair Programming