揭開極端編程的神秘面紗：結對致勝
——兩人智慧勝一人
作者：Roy W. Miller 本文選自：IBM developerWorks中國網站 2003年05月30日
某些 XP 實踐讓項目經理感到可笑，而讓程序員畏縮。結對編程（或結對）就是其中一種。根據一些 XP 評論家的反饋，結對編程獲得了“最可能令人不快的方法”的“獎項”— 也就是說，如果您不得不給它一個頭銜的話。本月，XP 專家 Roy Miller 討論了這種編寫代碼的基本方法，包括對于結對的誤解、為什么那么多軟件開發人員都討厭它以及為什么它對項目的成功是如此重要。請在本文的論壇中與作者和其他讀者分享您對本文的看法。（您也可以單擊本文頂部或底部的“討論”來進入論壇。）
在過去五十年里，編程基本上是一種單干的職業。哦，當然，程序員也與別人交談，尤其在項目的需求收集階段。但一旦開始編碼，大多數公司的程序員就會一頭埋進他們的辦公室或隔間里獨自工作。經理們并不太在意，因為程序員獨自工作更易于制定工作計劃，而且讓許多人同時處理問題的不同部分似乎效率更高。后來出現了 XP 倡導者，他們說程序員應該結對編寫代碼。如果您將這種說法講給大多數經理和程序員聽，肯定會受到異樣的注視，就好象他們為您的誤入歧途而感到可惜。其原因就是因為他們不知道結對究竟是什么，或者他們確實知道結對，但認為這是一種不明智或瘋狂的編碼方法。
結對是什么 — 它不是什么
當我第一次向不熟悉結對的人提起這個概念時，我會得到三種常見的反應：
◆ 噢？
◆聽起來很有趣。
◆荒唐／愚蠢／效率低下／填寫您喜歡的貶義詞吧。
相對于第三種反應，我能更容易地應對前兩種反應，因為前兩種反應通常來自于需要更多信息的人。在第一種情況中，這個人完全不知道我正在談論的內容，因此我給他一個快速定義：
結對就是兩個人一起解決同一個編程問題。
正如我在本專欄的第二篇文章“ 揭開極端編程的神秘面紗：“XP 精華”重訪，第 2 部分”中所說的，結對的機制看起來如下：
�。劢Y對］通常表示兩個開發人員共用一臺計算機、一臺監視器、一個鍵盤和一個鼠標（我發現兩臺監視器、兩個鍵盤和兩個鼠標更有趣、更高效，但一套設施也可以干得很好）。您和搭檔坐在鍵盤前。一個人駕駛（“駕駛員”），另一個人為他導航（“導航員”或“伙伴”）。
如果駕駛員停滯不前或受到挫折或者失去了思路，導航員和駕駛員可以互換角色。實際上，這種角色互換應該經常發生，有時可能每隔幾分鐘（甚至更頻繁）就互換一次。一旦您習慣了這種做法，并且適應了與您結對的特定人員，您就會進入這種流程，很自然地來回互換角色。
當我用這些話向說“噢？”的人描述結對時，他們的反應通常會變成“聽起來很有趣”或更可能是“荒唐”。他們可能會問關于結對如何在他們的特定情況中起作用的問題（請參閱本文的論壇，您可以在其中提出這些問題，并且查看我對在您之前提出這些問題的人的回答），他們也可能要說服我這不是一個可行的選擇。我稍后再討論如何應對說“荒唐”的人，首先讓我談談我聽到的最有趣的問題：為什么要結對？
結對的好處
您為什么要結對？簡單的回答是結對可以：
◆減少風險
◆使團隊生產效率更高
◆生成更好的代碼
風險會使大多數團隊停滯不前�；叵胍幌履纳弦粋�項目。我敢打賭您會想起您想要做但卻不敢冒險去做的一些事，這是因為您太想求穩。別人也一樣。減少風險的最佳方法是確保團隊中的每個人都完全熟悉系統的所有部件以及對系統的所有更改。技術講解和設計文檔很有用，但對于大多數快節奏的項目，它們并不能很好且迅速地傳播知識。傳播知識最有效的方法是讓一個知道代碼的人與不知道代碼的人一起解決問題。
結對是經理和團隊減少風險并防止因更改而毀掉團隊必須運用的最好的工具之一。當團隊成員結對時，所有設計決策和代碼更改都至少由兩個人完成。通過讓程序員結對，經理確保了更多人熟悉代碼以及它經歷的更改。此外，兩個人編寫的代碼總比一個人寫的代碼好。兩個人的智慧確實勝過一個人的，對于影響整個系統的設計決策更是如此。無論一個程序員多么聰明（或自以為多么聰明），第二種意見有助于避免由于無知、自大或只是由于疏忽而產生錯誤決策。
雖然許多程序員保持專心致志可能沒有問題，但是讓其他人使我們這些凡夫俗子中的另一些人不出閃失當然也是有幫助的。當您嘗試解決令人沮喪的問題時，這特別有幫助。當您想要放棄時，旁邊有人鼓勵您，讓您繼續前進。團隊也不大可能忽略測試或其它重要的細節 — 只有這樣才會增加生產力。
在我采用 XP 之前的項目中，我的團隊隨著項目的進展緩慢提速，但隨著錯誤的增多最終又慢下來。但是，在 XP 項目中，我的團隊很快達到難以置信的快速，而且一直保持著這個速度。例如，最近團隊的速度從第一次迭代的 14 個環節點到第 5 次反復的 60 個環節點以上（請參閱參考資料以獲取關于環節點的 XP 概念的更多信息）。其主要原因是我們的代碼比我以前所見過的代碼更成熟，而且成熟得更快，這就允許我們隨著項目的發展而更快地前進。當團隊成員結對時，至少有一個人一直在復查代碼。這是我聽說過的最好的代碼復查。
XP 中簡單性的價值建議我團隊中的每個人應該在有效的前提下，對代碼和過程采用最簡單的方法。當您剛開始時，結對似乎并不簡單。這會有點不舒服，需要去習慣它。但 XP 的價值、原理和實踐不是鼓勵您盡可能地做最簡單的事情 — 它們鼓勵您在有效的前提下，做最簡單的事情。如果有些事情雖簡單（比如，讓每個人獨自編碼）但沒有效果，那么它并不是行之有效的最簡單的事情。有時，在您適應之前，行之有效的最簡單的事情難以做到。結對就是一個好例子。以我的經驗來看，不結對通常不如結對有效。
為什么有些程序員討厭它
我遇到許多程序員，他們都認為結對是荒唐的舉動。其中許多人都拒絕嘗試它，甚至拒絕以開放的心態來討論它。我認為他們強烈的反感來自于幾個原因：
◆他們相信結對會“減緩他們的速度”。
◆他們曾嘗試過結對，卻發現它效率太低和／或壓力太大。
◆他們需要時間來獨自解決問題。
◆從更深的角度來看，他們害怕讓其他人發現他們并非始終是天才。
程序員往往很自大，而且許多程序員容易變得自以為是。有時，他們可以用絕好的聰明才智和技術來虛張聲勢，甚至那些沒有才能的人都可能認為他們很行。盡管如此，即使世界上最好的程序員也可以從最低級的黑客身上學到東西 — 這是他們中的許多人忽略的一個事實。如果程序員說結對會減慢他的速度，也許他是對的。也許與別人一起工作會減緩他個人的速度。但用兩個人的智慧來解決問題的好處可以抵消個人生產力的短期下降。大多數程序員說結對會減緩他們速度時的意思是：“我比其他人更好，讓他參與我的工作只會拖累我�！�
結對并不適合所有人�；ㄒ徽鞎r間在隔間里與另一個人探討想法也許一直以來都不是您這樣的典型程序員的想法，而且它可能帶來壓力。但是壓力可以帶來好處。與人交往通常比獨自一人更困難，但每個程序員遲早必須與別人（或至少是其他程序員）交流，以便完成工作。結對是一種習慣，它有助于人與人之間的交流，就象編碼一樣，自然而并不可怕。
即使程序員接受了交流是學習和創造的更佳方式這一想法，他仍可能會感到他好象需要一些“獨處時間”來解決問題。我可以理解。有時，集中精神思考問題而不必向別人講清自己的想法是我解決手頭問題時必需的。但是，我相信這種對獨處時間的需求實際上是某些更深層次的癥狀。
在程序員解釋他們為什么認為結對編程很愚蠢的所有原因中，最可怕的原因是他們害怕。這就是人。沒有人想要暴露他的弱點和無知。許多程序員很難承認自己并不聰明，但他們更難以接受暴露這一點。他們討厭可能會證明他們錯了的想法。但我們需要暴露我們的弱點，以便從中吸取教訓，進而獲得提高。結對可以讓您成為更健全的專業軟件開發人員。
為什么有些經理討厭它
我認為許多經理討厭結對編程這個想法是由于以下原因：
◆ 條件反應
◆害怕他們的同級或上司的想法
◆為他們工作的程序員會反對
尤其在過去的一百年里，經理們已經非常習慣于相信多個人完成同一項任務從本質上說是效率低下的。在某些行業，如制造業，也許確實如此。但對于腦力工作，如軟件開發，未必是這樣。但是，只要有人開始討論使程序員結對，許多經理就會說：“效率太低�！蔽彝ǔf：“沒錯，很對�！眲摻ê玫能浖⒉皇且粋�效率優化問題。它是發明。發明是一件棘手的事情，在這一情形中，效率不起作用�，F在，如果兩個人坐在一起，但一個人只是看著另一個人的肩膀，而不參與工作，那效率當然低了。相反，如果兩個程序員共同工作以解決同一個問題，兩個全神貫注的人的想法是非常有用的。解決方案將幾乎總是更好的。如果一個人靈光閃現，另一個人會通過關注該想法的最簡單實現，從而起平衡作用。如果那個人過于強調簡單，而將正確的想法變成了愚蠢的，那么另一個人就可以制止這種愚蠢的行為。經理在這個問題上的墨守成規是錯的，而且大多數經理都沒有（或者無法）對此產生疑問。
許多經理回避結對的原因之一就是他們害怕如何讓別人了解結對。如果他們的老板看到幾個程序員坐在一起看著同一個監視器，他也許會沖進經理的辦公室，要求知道為什么浪費“資源”。如果同級經理偶爾來與您一起討論一些事情，看到程序員都結對工作，也許會有傳言說這個經理頭腦發昏了。那的確令人害怕。但我認為對團隊真正（相對于表面的）生產力的損害勝過對經理名譽的損害。結果會證明一切。假設他讓他的程序員結對工作，而不是每個人獨自工作。如果結對實驗得到了比通常更好的結果，那么取得結果的方法就不再是個問題。它甚至可能會成為標準。
請注意，順便說說，我假設該經理讓他的程序員結對工作。如果程序員不想這么做，該怎么辦呢？我認為，這就是大多數開發團隊不進行結對工作的最大原因。我與許多認為應該進行結對的經理討論過。但是，還是那些經理告訴我：如果強迫他們的程序員結對，這些程序員會威脅要辭職（有時會是全體辭職）。您已經知道為什么程序員會有那種反應，但經理應該怎么做呢？我認為只有三種選擇：
◆尋找愿意結對的人，管理他們。
◆強迫團隊（包括反對者）嘗試實驗性地結對工作兩星期。
◆到其它有愿意在您手下進行結對工作的人的地方去。
許多人的反映是我天真得無藥可救了，在被這些口水淹沒之前，請允許我說：我意識到第一種選擇通常不可行。大多數經理沒有那么大的權力。第三種選擇有點過激，但可以立即實現。但是，會證明第二種選擇也許更有趣。
有些研究（雖然是利用大學生做的）顯示了最初討厭結對想法的程序員在嘗試之后最終喜歡上這種方式（請參閱參考資料中由 Alistair Cockburn 和 Laurie Williams 撰寫的 The Costs and Benefits of Pair Programming 以獲取更多詳細信息）。強迫人們做一些事是不明智的，但有時打破人們關于其集體或個人意識陳規是必要的。試著強迫人們花很短的時間來嘗試結對工作。如果他們反對，對他們強調只執行兩周。在兩周內，任何人都可以忍受做任何事。那些在兩周后仍沒有被說服的人在兩個月后也不會被說服 — 而即使他們會信服，您可能也永遠看不出來，因為他們決不會嘗試結對工作兩個月。經理的最大愿望是兩周時間可以讓大多數程序員相信結對工作的前景光明。如果不能做到，那么您永遠只能有第一種和第三種選擇。
一個好經理不會強迫執行結對工作很長時間。那就不只是不明智了。這很危險。這很容易樹敵。如果您的程序員都很生氣而要辭職，那么您就要獨自承擔責任。進行實驗是有益的。最好在一些團隊成員接受之后再做改變。壓迫通常會失敗。
告訴我您的想法
您可以幫助我確定下個月要寫什么。您對 XP 最大的疑問是什么？您認為什么是十分愚蠢的、不明智的、不專業的或不可行的？什么是最讓您困惑的方法？請在本專欄的論壇中提出您的建議。
結對究竟是什么
可以從兩個層面討論結對。第一層是機制 — 關于什么構成了“結對”的原始描述。第二層，也就是更深入的一層是人與人之間的。結對是您與團隊中的成員一起工作。那是工作中最具挑戰性的部分 — 與您未曾打過交道的人合作，只是因為（通常）別人告訴您必須這么做。因為每個人都是獨一無二的，所以無論是對您還是對對方，這可能是一個挑戰，。正如 Ken Auer 和我在 Extreme Programming Applied（請參閱參考資料）中指出的，人際關系是很難處理的，尤其是在政策和隱藏的操作規程可能使事情復雜化的職業環境中。即使只是幾個小時，這些類型的關系都不是大多數人感興趣的事。這是一個極端想法，不是人人都這么想。但它也可以對您的職業生涯產生一些最有益的經驗。
參考資料
請閱讀 Alistair Cockburn 和 Laurie Williams 撰寫的 The Costs and Benefits of Pair Programming（XP2000 建議，2000 年）中關于結對編程的經濟效益的內容。
請閱讀 Laurie Williams 和 Robert Kessler 撰寫的 Pair Programming Illuminated（由 Addison-Wesley 于 2002 年出版）以獲取關于結對的更理論性（和實際）的討論。
Ken Auer 和 Roy Miller 合著的 Extreme Programming Applied: Playing to Win（由 Addison-Wesley 于 2001 年出版）提供了關于如何應用 XP 的更多討論。
整個 Demystifying Extreme Programming 系列提供了對 XP 方法的深入研究（其中有一些個人觀點）。文章“揭開極端編程的神秘面紗：關注價值”（2003 年 2 月）詳細討論了環節點和它們對項目團隊意味什么，“揭開極端編程的神秘面紗：“XP 精華”重訪，第 2 部分”（2002 年 9 月）討論了結對編程的機制。
在“Extreme Programming with IBM VisualAge for Java”（developerWorks，2001 年 4 月）中，了解 VisualAge for Java 為什么是 XP 團隊的優秀工具。
有關可以支持 XP 團隊的其它工具，請閱讀“Excerpt from Java Tools for Extreme Programming”（developerWorks，2002 年 7 月）。
在 developerWorks Java 技術專區中可以找到關于 Java 編程各方面內容的大量文章。
關于作者
Roy W. Miller 從事軟件開發和技術咨詢工作將近十年了，最初在 Andersen Consulting（現在的 Accenture）工作，目前則在位于北卡羅萊納州的 RoleModel Software, Inc. 工作。他使用過重量級方法和靈活方法，包括 XP。他與人合著了 Addison-Wesley XP 系列叢書中的一本（Extreme Programming Applied: Playing to Win），目前他正在撰寫一本關于復雜性、緊急情況和軟件開發的書（暫定標題為 Growing Software: Exploding the Myth of Prediction and Control）。請通過 rmiller@rolemodelsoft.com. 或 roy@roywmiller.com. 與 Roy 聯系。您也可以通過 www.roywmiller.com. 訪問他的個人網站
『轉自 IBM developerWorks中國網站』
文章來源于領測軟件測試網 http://www.kjueaiud.com/
