RUP/XP 方針：成對編程
Robert C. Martin
Object Mentor, Inc.
Rational 軟件白皮書
翻譯整理：BrokenDoor 2002/3/4
--------------------------------------------------------------------------------
簡介
成對，概要說明
--------------------------------------------------------------------------------
成對編程是軟件開發中兩個人一起編寫一個項目的一種技術。每個伙伴工作在同一臺機器上，當一個程序員在寫代碼時，另一個伙伴在一旁觀看，同時認真所寫的代碼。寫代碼者從戰術上考慮具體實現，其伙伴則從戰略上考慮整個程序。他們之間頻繁的交換角色，這樣將使得可以更快寫完代碼，并且減少錯誤，更重要的是：代碼將至少有兩個人非常清楚的掌握。
成對的案例
--------------------------------------------------------------------------------
考慮一個典型的代碼審視的工作。一個需要一人8小時開發的模塊由8個人花一小時審視。也就是等于總共要花費16個工作人日。然而，審視者不能保障必需的時間去熟悉代碼，而且他們的審視也相當的膚淺。單個人開發確實能非常熟悉該模塊，但是可能太熟悉了以至于不能發現漏洞。
對比成對編程的實踐方法。如果這個模塊需要兩人合作8小時來開發，總共需16工作人日。然而，這種情況下，兩個伙伴將會非常熟知這個模塊的代碼。在開發過程中所隱含的一些錯誤也將被另一個伙伴發現。
成對編程的實踐是簡單的，但是是一種簡單而有效的編寫和審視代碼方法。兩人同時熟知代碼，并且將錯誤漏洞出現在代碼中的可能性大大減少。代碼將有一個良好的結構。當然成對還有更多的益處：
成對更有勇氣：一個人不敢嘗試的東西他的伙伴將有勇氣去嘗試并扼殺其原有的評估；
成對能鼓勵團隊：由于代碼不是一個人獨立完成的，而將是屬于整個團隊所有。
成對促使知識的傳播：由于在開發的過程中不斷的交換伙伴，而使每個成員將熟知系統的每個一個模塊。
成對能提高生產力：一個人在開發的過程中將會出現一段疲勞、消極的時期。如果雙人變成，則可以相互促進，當一方疲勞時，他們可以交換角色。他們將能保持強度（比一個人工作強）。
成對是一件有趣的事：和他人一起工作是一件有意義的，非常刺激而且簡單的游戲。它將會提高工作滿意度和提高士氣。
實踐規則
成對
--------------------------------------------------------------------------------
成對開始于某一個程序員承擔了一個任務的責任并且請求其他人幫助的時候。規則是：當你被請求提供幫助的時候，你必須說可以。這并不是說你需要立刻停下正在做的事情。這其實時說你必須商定好一個時間你能夠提供幫助而另一個時間獲得幫助作為回報。
成對中的伙伴并不承擔任務的責任。這個責任還是歸任務所有者保留。并且成對中的伙伴也不保證說一定要和任務所有者一起直到任務完成。成隊的伙伴指保證完成提供幫助。
成對中的一個成員成為驅動者，而另外一個則在一旁觀看。驅動者鍵入代碼，運行編譯器，運行測試程序，并繼續任務。旁觀者則檢查每一個鍵入，每一個命令，每一個測試結果，并且提供幫助和建議。在所有的時間里每一個成員都被充分使用了。
某些時候驅動者會更了解要完成什么工作，而旁觀者則只是簡單的跟隨。而另外一些時候，旁觀者將會替驅動者決定要做什么。有些時候驅動者失敗了并且將鍵盤遞給旁觀者，然后兩人互換角色。還有些時候，旁觀者會要求拿過鍵盤并且互換角色。這些情況將在成隊的過程中經常出現。
交換成對
--------------------------------------------------------------------------------
成隊的伙伴并不是長期固定的。一個典型的成對過程將僅僅持續半天左右。每一個伙伴都可以因為任何原因選擇退出成對。當這種情況出現的時候，任務的所有者必須找到另外一個成對伙伴。這也可能意味著是該任務所有者回報幫助給上周的某一個伙伴的時候了，也可能他或她需要請求一個對當前特殊的問題有著合適經驗的人提供幫助。
這種成對的交換會形成系統的相關知識在整個開發隊伍中的傳播。在很短的時間內，每一個團隊成員就將有在系統的幾乎每一個部分工作過的經驗了。這急劇地減少了項目重寫的程度，并且讓每一個程序員在處理整個系統的時候更有信心。
集體代碼所有權
--------------------------------------------------------------------------------
因為每個人都在為系統的不同模塊工作，因此沒有人擁有某一個特定的模塊。這表明對系統的責任不會按照每個模塊為基礎分割開來。更好的方式是，整個團隊擁有整個系統的集體責任。每一個團隊成員都可以為任何原因簽出并修改系統的任何一個模塊。當一個雙人組合修改模塊X而導致了模塊Y的單元測試失敗的時候，這個組合將會直接修訂模塊Y。
漫步和協作
--------------------------------------------------------------------------------
成對編程時一個非常熱烈的交流形式�？陬^的對話經常會變成爭論，局外人通常會有理解的問題。作為一個局外人，你也許會聽到兩人發出特別的單詞好像：“分號”，或者“關閉花括號”�；蛘吣憧赡苤皇锹牭揭恍┎磺宄膰Ｂ曌鳛槌绦騿T們同意或者不同意屏幕上出現的內容。倆人都忙碌于正在出現的代碼中以至于很多交流都是無聲的。肢體語言占了很重要的位置。一個成隊的伙伴不需要出聲詢問就可以說出他的同伴什么時候對代碼不滿意。一個鬼臉，一聲嘆息，一陣不安——所有的集合起來都增加了伙伴之間的交流帶寬。有些時候一個伙伴會搶過鼠標，而另一個則操作鍵盤。拿鼠標的人控制需要在模塊中工作的位置。拿鍵盤的人控制在此位置修改和添加的內容。另外一些時候，一個伙伴可能在鍵入代碼，而另外一個伙伴將預知一個需要的函數調用并且打開API文檔中相應的說明頁。
當一個伙伴疲倦的時候，另外一個人可以接過手來，允許他或者她的伙伴休息一下來充當相對的角色。其它的時候，兩個伙伴都會有高昂的精神面貌并且會經常的交換鼠標和鍵盤。
總而言之，這里只有很少的規則和過程。真正需要約束的僅僅是兩個伙伴都必須維持高昂的精神面貌并且倆人之間交流必須是熱烈的。如果成對中的一個伙伴正在鍵入代碼而另外一個家伙正看著窗外的話，則成對只是虛有其表。
單獨的一個程序員能做什么呢？
--------------------------------------------------------------------------------
你不可能在所有的時間內都保持成對。一些項目——那些選用極端編程(XP)(參考資料1?)——遵循的一個規則就是必須由成對完成所有產品代碼。在這種情況下，在你沒有成對時你可以去查看一下電子郵件，閱讀一些有關新技術或者API的技術資料，看一下那些你不太熟悉的代碼，或者跟投資者探討一下當前的迭代狀況或者未來的計劃。實際上，總有一些適合的事情可以讓一個程序員在沒有找到伙伴的那幾個小時里去做的。
有一些項目對成對要求的沒有那么嚴格。有一些會允許單獨的程序員們去編寫測試代碼。還有一些允許單獨的程序員們去編寫抽象類和接口。也還有一些只是簡單的允許程序員們決定什么時候最好需要成對。有一件事是很清楚的，無論如何——研究已經表明當實踐成對編程的時候錯誤率會很顯著地降低。
有一些人不喜歡成對
--------------------------------------------------------------------------------
一些人對成對編程的概念感覺不適應。在我們的經驗中，這些人實際上在嘗試了一周左右后發現他們的不適應消失了，并且他們喜歡成對和發現它是很用處的。只有很少的人會繼續不喜歡這個實踐。因此，對大多數人來講，嘗試并且習慣它是一個很簡單的問題。對于那些真正了嘗試過并且依然感覺到不適應這個實踐的人們，團隊就必須去找到一些適合他們做的事情。
設備，方便以及后勤
顯示器和鍵盤的布置
--------------------------------------------------------------------------------
設備的布置對成功的成對實踐是很重要的。如果伙伴們不能坐到彼此的旁邊并且很快的交換鍵盤的話一個成對很難實施得很好。規則是：你必須能夠來回的拿到鍵盤和鼠標而不需要交換座位。
最好的安排通常是一個漂亮的長平板桌。將顯示器放在中間然后正對著顯示器放兩把椅子。坐下來讓顯示器在你們之間。確保很容易能在你們之間挪動鍵盤和鼠標。同時確保在你拿到鍵盤的時候，你能夠很舒適并且能夠坐直。確保顯示器能夠讓兩個伙伴都看得清楚而不需要轉動它。
大房間
--------------------------------------------------------------------------------
為了便于交換成對的伙伴，一般都希望能夠在一個類似棒球候補球員區的環境下工作。在一個房間里放置多個成對用的工作站。使用有輪子的椅子和油布或者瓷磚地板。排列工作站讓成對的伙伴們都能面對面。這樣做的目的是為了增加交流。有些時候最重要的交流就是那些偶然發生的。我們想讓這種交流出現的幾率能夠增加。
在角落里
--------------------------------------------------------------------------------
現今的許多小單間都將工作站放置到角落里。程序員們面對著角落坐下來在他或她的面前是一個顯示器。當然這樣會便于單人工作，但是在這種環境下成對編程幾乎是不可能的。如果你有一個將工作站放在角落的小單間，那么在其他地方放置一些成對用的工作站——也許在一個會議室。在一個會議桌上使用一個筆記本電腦進行成對編程常常是很有效的方式。
問題和關注
成對讓生產力減半
--------------------------------------------------------------------------------
這種說法建立在以下的理由上，兩個人在一個任務上一起工作會消耗兩倍于一個人在同樣的任務上工作的所花費的時間。這看上去合情合理，但這卻并不是真實情況。根據研究(參考資料2?)表明很少的，即便有，生產力會在成對工作的情況下喪失。同樣的研究證明了成對可以大大的降低錯誤率，以及程序代碼的大小，同時極大地增加了工作的樂趣。
成對伙伴間的爭論
--------------------------------------------------------------------------------
任務的所有者有所有設計爭論的最終決定權，但是處理爭論的最好的方式是對兩種設想都進行嘗試并選擇工作得最好的那種。
專家
--------------------------------------------------------------------------------
傳統的至理名言給出的建議是對某一個特殊領域有專長的程序員，例如數據庫或者圖形用戶界面，應該獨自在這些領域發揮作用。但是在一個成對編程的環境下，這些專家成為那些沒有這方面特長的伙伴的最好的導師。程序員們可以簽上一個不在他們的專長領域范圍內的任務然后征求專家們的幫助。這樣，專家的知識就開始在整個團隊的范圍內傳播，極大的減少了項目反復的程序。
噪音
--------------------------------------------------------------------------------
一個成對地伙伴可能在他們編程時產生噪音。一個坐滿成對伙伴的大房間會保持頻繁的低低的嗡嗡聲。有人會感覺到這些噪音令人煩悶以及分散注意力。這并不能證明是一個重大的問題。如果你覺得這些噪音令人煩悶，你可以走到會客室坐一會兒。
牛仔
--------------------------------------------------------------------------------
許多團隊會發現他們是一到兩個牛仔式編碼者的足以自豪的擁有者。這些牛仔是一些比其他任何都能更快地完成任務，不能和其他人合作，并且任何人都不被允許（或者是如果允許的話，也沒有能力）去閱讀他們的代碼。對于這些開發者最好的處理方法是讓他們離開項目或者承擔一個不需要他們編寫產品代碼的角色。也許他們能夠編寫一些臨時的工具或者做一些瘋狂折磨式的測試工作。
習慣障礙和障礙形式
--------------------------------------------------------------------------------
有一些人使用QWERTY式的鍵盤。另一些人更習慣于DVORAK式的。一些人需要特制的鍵盤，鼠標，顯示器，腳踏開關，等等，等等。一些人在編程時不能沒有耳機和喧鬧的音樂。另一些人必須在他們周圍擺滿空箱子。一些人喜歡用emacs編輯器。另外一些人喜歡VI。甚至還有一些人喜歡用WordPad?.
實際上，這些可以指出的障礙是數不清的。但是每一種障礙和每一個人都可以通過一些想法解決并且有辦法進行折衷。一個讓這些事情阻止他們的團隊是不可能在他們嘗試的任何努力中取得成功的。
團隊如何規劃成對的計劃？
--------------------------------------------------------------------------------
我們并不認為任務需要指定給一個雙人組。更好的方式時每一個開發者需要承擔一些任務的責任。我們喜歡非正式地成對。每一個開發者，從事他或她自己承擔的責任，請求其他開發人員提供暫時的幫助。任務的所有者保持著所有權和責任。成對的伙伴僅僅是幫忙的人。
每一個開發者必須在評估任務的時候計入他或她作為其他人的開發伙伴的時間。
總結
成對編程是一種成功試驗過的，令人滿意的代碼審查的替代方法。不僅如此，它還是一種編寫軟件系統的革新的途徑。帶來的好處也不僅限于生產力和質量，而且對一些像團隊士氣和精神風貌等方面帶來好的影響。
參考資料
(1) 解說極端編程(eXtreme Programming eXplained)， Kent Beck, Addision Wesley, 2000.
(2) 強調成對編程的案例，Laurie Williams, 猶他州立大學， 7/8月 IEEE 軟件。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
