揭開極端程式設計的神祕面紗：結對致勝

　　某些 XP 實踐讓專案經理感到可笑，而讓程式設計師畏縮。結對程式設計（或結對）就是其中一種。根據一些 XP 評論家的反饋，結對程式設計獲得了“最可能令人不快的方法”的“獎項”— 也就是說，如果您不得不給它一個頭銜的話。本月，XP 專家 Roy Miller 討論了這種編寫程式碼的基本方法，包括對於結對的誤解、為什麼那麼多軟體開發人員都討厭它以及為什麼它對專案的成功是如此重要。請在本文的論壇中與作者和其他讀者分享您對本文的看法。（您也可以單擊本文頂部或底部的“討論”來進入論壇。） 

　　在過去五十年裡，程式設計基本上是一種單幹的職業。哦，當然，程式設計師也與別人交談，尤其在專案的需求收集階段。但一旦開始編碼，大多數公司的程式設計師就會一頭埋進他們的辦公室或隔間裡獨自工作。經理們並不太在意，因為程式設計師獨自工作更易於制定工作計劃，而且讓許多人同時處理問題的不同部分似乎效率更高。後來出現了 XP 倡導者，他們說程式設計師應該結對編寫程式碼。如果您將這種說法講給大多數經理和程式設計師聽，肯定會受到異樣的注視，就好象他們為您的誤入歧途而感到可惜。其原因就是因為他們不知道結對究竟是什麼，或者他們確實知道結對，但認為這是一種不明智或瘋狂的編碼方法。 

　　結對是什麼 — 它不是什麼 

　　當我第一次向不熟悉結對的人提起這個概念時，我會得到三種常見的反應： 

　　◆ 噢？ 

　　◆聽起來很有趣。 

　　◆荒唐／愚蠢／效率低下／填寫您喜歡的貶義詞吧。 

　　相對於第三種反應，我能更容易地應對前兩種反應，因為前兩種反應通常來自於需要更多資訊的人。在第一種情況中，這個人完全不知道我正在談論的內容，因此我給他一個快速定義： 

　　　　結對就是兩個人一起解決同一個程式設計問題。 

　　正如我在本專欄的第二篇文章“ 揭開極端程式設計的神祕面紗：“XP 精華”重訪，第 2 部分”中所說的，結對的機制看起來如下： 

　　［結對］通常表示兩個開發人員共用一臺計算機、一臺監視器、一個鍵盤和一個滑鼠（我發現兩臺監視器、兩個鍵盤和兩個滑鼠更有趣、更高效，但一套設施也可以乾得很好）。您和搭檔坐在鍵盤前。一個人駕駛（“駕駛員”），另一個人為他導航（“導航員”或“夥伴”）。 

　　如果駕駛員停滯不前或受到挫折或者失去了思路，導航員和駕駛員可以互換角色。實際上，這種角色互換應該經常發生，有時可能每隔幾分鐘（甚至更頻繁）就互換一次。一旦您習慣了這種做法，並且適應了與您結對的特定人員，您就會進入這種流程，很自然地來回互換角色。 

　　當我用這些話向說“噢？”的人描述結對時，他們的反應通常會變成“聽起來很有趣”或更可能是“荒唐”。他們可能會問關於結對如何在他們的特定情況中起作用的問題（請參閱本文的論壇，您可以在其中提出這些問題，並且檢視我對在您之前提出這些問題的人的回答），他們也可能要說服我這不是一個可行的選擇。我稍後再討論如何應對說“荒唐”的人，首先讓我談談我聽到的最有趣的問題：為什麼要結對？ 

　　結對的好處 

　　您為什麼要結對？簡單的回答是結對可以： 

　　◆減少風險 

　　◆使團隊生產效率更高 

　　◆生成更好的程式碼 

　　風險會使大多數團隊停滯不前。回想一下您的上一個專案。我敢打賭您會想起您想要做但卻不敢冒險去做的一些事，這是因為您太想求穩。別人也一樣。減少風險的最佳方法是確保團隊中的每個人都完全熟悉系統的所有部件以及對系統的所有更改。技術講解和設計文件很有用，但對於大多數快節奏的專案，它們並不能很好且迅速地傳播知識。傳播知識最有效的方法是讓一個知道程式碼的人與不知道程式碼的人一起解決問題。 

　　結對是經理和團隊減少風險並防止因更改而毀掉團隊必須運用的最好的工具之一。當團隊成員結對時，所有設計決策和程式碼更改都至少由兩個人完成。通過讓程式設計師結對，經理確保了更多人熟悉程式碼以及它經歷的更改。此外，兩個人編寫的程式碼總比一個人寫的程式碼好。兩個人的智慧確實勝過一個人的，對於影響整個系統的設計決策更是如此。無論一個程式設計師多麼聰明（或自以為多麼聰明），第二種意見有助於避免由於無知、自大或只是由於疏忽而產生錯誤決策。 

　　雖然許多程式設計師保持專心致志可能沒有問題，但是讓其他人使我們這些凡夫俗子中的另一些人不出閃失當然也是有幫助的。當您嘗試解決令人沮喪的問題時，這特別有幫助。當您想要放棄時，旁邊有人鼓勵您，讓您繼續前進。團隊也不大可能忽略測試或其它重要的細節 — 只有這樣才會增加生產力。 

　　在我採用 XP 之前的專案中，我的團隊隨著專案的進展緩慢提速，但隨著錯誤的增多最終又慢下來。但是，在 XP 專案中，我的團隊很快達到難以置信的快速，而且一直保持著這個速度。例如，最近團隊的速度從第一次迭代的 14 個環節點到第 5 次反覆的 60 個環節點以上（請參閱參考資料以獲取關於環節點的 XP 概念的更多資訊）。其主要原因是我們的程式碼比我以前所見過的程式碼更成熟，而且成熟得更快，這就允許我們隨著專案的發展而更快地前進。當團隊成員結對時，至少有一個人一直在複查程式碼。這是我聽說過的最好的程式碼複查。 

　　XP 中簡單性的價值建議我團隊中的每個人應該在有效的前提下，對程式碼和過程採用最簡單的方法。當您剛開始時，結對似乎並不簡單。這會有點不舒服，需要去習慣它。但 XP 的價值、原理和實踐不是鼓勵您儘可能地做最簡單的事情 — 它們鼓勵您在有效的前提下，做最簡單的事情。如果有些事情雖簡單（比如，讓每個人獨自編碼）但沒有效果，那麼它並不是行之有效的最簡單的事情。有時，在您適應之前，行之有效的最簡單的事情難以做到。結對就是一個好例子。以我的經驗來看，不結對通常不如結對有效。 

　　為什麼有些程式設計師討厭它 

　　我遇到許多程式設計師，他們都認為結對是荒唐的舉動。其中許多人都拒絕嘗試它，甚至拒絕以開放的心態來討論它。我認為他們強烈的反感來自於幾個原因： 

　　◆他們相信結對會“減緩他們的速度”。 

　　◆他們曾嘗試過結對，卻發現它效率太低和／或壓力太大。 

　　◆他們需要時間來獨自解決問題。 

　　◆從更深的角度來看，他們害怕讓其他人發現他們並非始終是天才。 

　　程式設計師往往很自大，而且許多程式設計師容易變得自以為是。有時，他們可以用絕好的聰明才智和技術來虛張聲勢，甚至那些沒有才能的人都可能認為他們很行。儘管如此，即使世界上最好的程式設計師也可以從最低階的黑客身上學到東西 — 這是他們中的許多人忽略的一個事實。如果程式設計師說結對會減慢他的速度，也許他是對的。也許與別人一起工作會減緩他個人的速度。但用兩個人的智慧來解決問題的好處可以抵消個人生產力的短期下降。大多數程式設計師說結對會減緩他們速度時的意思是：“我比其他人更好，讓他參與我的工作只會拖累我。” 

　　結對並不適合所有人。花一整天時間在隔間裡與另一個人探討想法也許一直以來都不是您這樣的典型程式設計師的想法，而且它可能帶來壓力。但是壓力可以帶來好處。與人交往通常比獨自一人更困難，但每個程式設計師遲早必須與別人（或至少是其他程式設計師）交流，以便完成工作。結對是一種習慣，它有助於人與人之間的交流，就象編碼一樣，自然而並不可怕。 

　　即使程式設計師接受了交流是學習和創造的更佳方式這一想法，他仍可能會感到他好象需要一些“獨處時間”來解決問題。我可以理解。有時，集中精神思考問題而不必向別人講清自己的想法是我解決手頭問題時必需的。但是，我相信這種對獨處時間的需求實際上是某些更深層次的症狀。 

　　在程式設計師解釋他們為什麼認為結對程式設計很愚蠢的所有原因中，最可怕的原因是他們害怕。這就是人。沒有人想要暴露他的弱點和無知。許多程式設計師很難承認自己並不聰明，但他們更難以接受暴露這一點。他們討厭可能會證明他們錯了的想法。但我們需要暴露我們的弱點，以便從中吸取教訓，進而獲得提高。結對可以讓您成為更健全的專業軟體開發人員。 

　　為什麼有些經理討厭它 

　　我認為許多經理討厭結對程式設計這個想法是由於以下原因： 

　　◆ 條件反應 

　　◆害怕他們的同級或上司的想法 

　　◆為他們工作的程式設計師會反對 

　　尤其在過去的一百年裡，經理們已經非常習慣於相信多個人完成同一項任務從本質上說是效率低下的。在某些行業，如製造業，也許確實如此。但對於腦力工作，如軟體開發，未必是這樣。但是，只要有人開始討論使程式設計師結對，許多經理就會說：“效率太低。”我通常會說：“沒錯，很對。”建立好的軟體並不是一個效率優化問題。它是發明。發明是一件棘手的事情，在這一情形中，效率不起作用。現在，如果兩個人坐在一起，但一個人只是看著另一個人的肩膀，而不參與工作，那效率當然低了。相反，如果兩個程式設計師共同工作以解決同一個問題，兩個全神貫注的人的想法是非常有用的。解決方案將幾乎總是更好的。如果一個人靈光閃現，另一個人會通過關注該想法的最簡單實現，從而起平衡作用。如果那個人過於強調簡單，而將正確的想法變成了愚蠢的，那麼另一個人就可以制止這種愚蠢的行為。經理在這個問題上的墨守成規是錯的，而且大多數經理都沒有（或者無法）對此產生疑問。 

　　許多經理迴避結對的原因之一就是他們害怕如何讓別人瞭解結對。如果他們的老闆看到幾個程式設計師坐在一起看著同一個監視器，他也許會衝進經理的辦公室，要求知道為什麼浪費“資源”。如果同級經理偶爾來與您一起討論一些事情，看到程式設計師都結對工作，也許會有傳言說這個經理頭腦發昏了。那的確令人害怕。但我認為對團隊真正（相對於表面的）生產力的損害勝過對經理名譽的損害。結果會證明一切。假設他讓他的程式設計師結對工作，而不是每個人獨自工作。如果結對實驗得到了比通常更好的結果，那麼取得結果的方法就不再是個問題。它甚至可能會成為標準。 

　　請注意，順便說說，我假設該經理讓他的程式設計師結對工作。如果程式設計師不想這麼做，該怎麼辦呢？我認為，這就是大多數開發團隊不進行結對工作的最大原因。我與許多認為應該進行結對的經理討論過。但是，還是那些經理告訴我：如果強迫他們的程式設計師結對，這些程式設計師會威脅要辭職（有時會是全體辭職）。您已經知道為什麼程式設計師會有那種反應，但經理應該怎麼做呢？我認為只有三種選擇： 

　　◆尋找願意結對的人，管理他們。 

　　◆強迫團隊（包括反對者）嘗試實驗性地結對工作兩星期。 

　　◆到其它有願意在您手下進行結對工作的人的地方去。 

　　許多人的反映是我天真得無藥可救了，在被這些口水淹沒之前，請允許我說：我意識到第一種選擇通常不可行。大多數經理沒有那麼大的權力。第三種選擇有點過激，但可以立即實現。但是，會證明第二種選擇也許更有趣。 

　　有些研究（雖然是利用大學生做的）顯示了最初討厭結對想法的程式設計師在嘗試之後最終喜歡上這種方式（請參閱參考資料中由 Alistair Cockburn 和 Laurie Williams 撰寫的 The Costs and Benefits of Pair Programming 以獲取更多詳細資訊）。強迫人們做一些事是不明智的，但有時打破人們關於其集體或個人意識陳規是必要的。試著強迫人們花很短的時間來嘗試結對工作。如果他們反對，對他們強調只執行兩週。在兩週內，任何人都可以忍受做任何事。那些在兩週後仍沒有被說服的人在兩個月後也不會被說服 — 而即使他們會信服，您可能也永遠看不出來，因為他們決不會嘗試結對工作兩個月。經理的最大願望是兩週時間可以讓大多數程式設計師相信結對工作的前景光明。如果不能做到，那麼您永遠只能有第一種和第三種選擇。 

　　一個好經理不會強迫執行結對工作很長時間。那就不只是不明智了。這很危險。這很容易樹敵。如果您的程式設計師都很生氣而要辭職，那麼您就要獨自承擔責任。進行實驗是有益的。最好在一些團隊成員接受之後再做改變。壓迫通常會失敗。 

　　告訴我您的想法 

　　您可以幫助我確定下個月要寫什麼。您對 XP 最大的疑問是什麼？您認為什麼是十分愚蠢的、不明智的、不專業的或不可行的？什麼是最讓您困惑的方法？請在本專欄的論壇中提出您的建議。 

　　結對究竟是什麼 

　　可以從兩個層面討論結對。第一層是機制 — 關於什麼構成了“結對”的原始描述。第二層，也就是更深入的一層是人與人之間的。結對是您與團隊中的成員一起工作。那是工作中最具挑戰性的部分 — 與您未曾打過交道的人合作，只是因為（通常）別人告訴您必須這麼做。因為每個人都是獨一無二的，所以無論是對您還是對對方，這可能是一個挑戰，。正如 Ken Auer 和我在 Extreme Programming Applied（請參閱參考資料）中指出的，人際關係是很難處理的，尤其是在政策和隱藏的操作規程可能使事情複雜化的職業環境中。即使只是幾個小時，這些型別的關係都不是大多數人感興趣的事。這是一個極端想法，不是人人都這麼想。但它也可以對您的職業生涯產生一些最有益的經驗。 

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14639675/viewspace-582365/，如需轉載，請註明出處，否則將追究法律責任。