RUP/XP 方針：成對程式設計

慮一個典型的程式碼審視的工作。一個需要一人8小時開發的模組由8個人花一小時審視。也就是等於總共要花費16個工作人日。然而，審視者不能保障必需的時間去熟悉程式碼，而且他們的審視也相當的膚淺。單個人開發確實能非常熟悉該模組，但是可能太熟悉了以至於不能發現漏洞。 

對比成對程式設計的實踐方法。如果這個模組需要兩人合作8小時來開發，總共需16工作人日。然而，這種情況下，兩個夥伴將會非常熟知這個模組的程式碼。在開發過程中所隱含的一些錯誤也將被另一個夥伴發現。 

成對程式設計的實踐是簡單的，但是是一種簡單而有效的編寫和審視程式碼方法。兩人同時熟知程式碼，並且將錯誤漏洞出現在程式碼中的可能性大大減少。程式碼將有一個良好的結構。當然成對還有更多的益處： 

成對更有勇氣：一個人不敢嘗試的東西他的夥伴將有勇氣去嘗試並扼殺其原有的評估； 

成對能鼓勵團隊：由於程式碼不是一個人獨立完成的，而將是屬於整個團隊所有。 

成對促使知識的傳播：由於在開發的過程中不斷的交換夥伴，而使每個成員將熟知系統的每個一個模組。 

成對能提高生產力：一個人在開發的過程中將會出現一段疲勞、消極的時期。如果雙人變成，則可以相互促進，當一方疲勞時，他們可以交換角色。他們將能保持強度（比一個人工作強）。 

成對是一件有趣的事：和他人一起工作是一件有意義的，非常刺激而且簡單的遊戲。它將會提高工作滿意度和提高士氣。 


實踐規則

成對 

--------------------------------------------------------------------------------

成對開始於某一個程式設計師承擔了一個任務的責任並且請求其他人幫助的時候。規則是：當你被請求提供幫助的時候，你必須說可以。這並不是說你需要立刻停下正在做的事情。這其實時說你必須商定好一個時間你能夠提供幫助而另一個時間獲得幫助作為回報。 

成對中的夥伴並不承擔任務的責任。這個責任還是歸任務所有者保留。並且成對中的夥伴也不保證說一定要和任務所有者一起直到任務完成。成隊的夥伴指保證完成提供幫助。 

成對中的一個成員成為驅動者，而另外一個則在一旁觀看。驅動者鍵入程式碼，執行編譯器，執行測試程式，並繼續任務。旁觀者則檢查每一個鍵入，每一個命令，每一個測試結果，並且提供幫助和建議。在所有的時間裡每一個成員都被充分使用了。 

某些時候驅動者會更瞭解要完成什麼工作，而旁觀者則只是簡單的跟隨。而另外一些時候，旁觀者將會替驅動者決定要做什麼。有些時候驅動者失敗了並且將鍵盤遞給旁觀者，然後兩人互換角色。還有些時候，旁觀者會要求拿過鍵盤並且互換角色。這些情況將在成隊的過程中經常出現。 

交換成對 

--------------------------------------------------------------------------------

成隊的夥伴並不是長期固定的。一個典型的成對過程將僅僅持續半天左右。每一個夥伴都可以因為任何原因選擇退出成對。當這種情況出現的時候，任務的所有者必須找到另外一個成對夥伴。這也可能意味著是該任務所有者回報幫助給上週的某一個夥伴的時候了，也可能他或她需要請求一個對當前特殊的問題有著合適經驗的人提供幫助。 

這種成對的交換會形成系統的相關知識在整個開發隊伍中的傳播。在很短的時間內，每一個團隊成員就將有在系統的幾乎每一個部分工作過的經驗了。這急劇地減少了專案重寫的程度，並且讓每一個程式設計師在處理整個系統的時候更有信心。 

集體程式碼所有權 

--------------------------------------------------------------------------------

因為每個人都在為系統的不同模組工作，因此沒有人擁有某一個特定的模組。這表明對系統的責任不會按照每個模組為基礎分割開來。更好的方式是，整個團隊擁有整個系統的集體責任。每一個團隊成員都可以為任何原因簽出並修改系統的任何一個模組。當一個雙人組合修改模組X而導致了模組Y的單元測試失敗的時候，這個組合將會直接修訂模組Y。 

漫步和協作 

--------------------------------------------------------------------------------

成對程式設計時一個非常熱烈的交流形式。口頭的對話經常會變成爭論，局外人通常會有理解的問題。作為一個局外人，你也許會聽到兩人發出特別的單詞好像：“分號”，或者“關閉花括號”。或者你可能只是聽到一些不清楚的嚕嚕聲作為程式設計師們同意或者不同意螢幕上出現的內容。倆人都忙碌於正在出現的程式碼中以至於很多交流都是無聲的。肢體語言佔了很重要的位置。一個成隊的夥伴不需要出聲詢問就可以說出他的同伴什麼時候對程式碼不滿意。一個鬼臉，一聲嘆息，一陣不安——所有的集合起來都增加了夥伴之間的交流頻寬。有些時候一個夥伴會搶過滑鼠，而另一個則操作鍵盤。拿滑鼠的人控制需要在模組中工作的位置。拿鍵盤的人控制在此位置修改和新增的內容。另外一些時候，一個夥伴可能在鍵入程式碼，而另外一個夥伴將預知一個需要的函式呼叫並且開啟API文件中相應的說明頁。 

當一個夥伴疲倦的時候，另外一個人可以接過手來，允許他或者她的夥伴休息一下來充當相對的角色。其它的時候，兩個夥伴都會有高昂的精神面貌並且會經常的交換滑鼠和鍵盤。 

總而言之，這裡只有很少的規則和過程。真正需要約束的僅僅是兩個夥伴都必須維持高昂的精神面貌並且倆人之間交流必須是熱烈的。如果成對中的一個夥伴正在鍵入程式碼而另外一個傢伙正看著窗外的話，則成對只是虛有其表。 

單獨的一個程式設計師能做什麼呢？ 

--------------------------------------------------------------------------------

你不可能在所有的時間內都保持成對。一些專案——那些選用極端程式設計(XP)(參考資料1?)——遵循的一個規則就是必須由成對完成所有產品程式碼。在這種情況下，在你沒有成對時你可以去檢視一下電子郵件，閱讀一些有關新技術或者API的技術資料，看一下那些你不太熟悉的程式碼，或者跟投資者探討一下當前的迭代狀況或者未來的計劃。實際上，總有一些適合的事情可以讓一個程式設計師在沒有找到夥伴的那幾個小時裡去做的。 

有一些專案對成對要求的沒有那麼嚴格。有一些會允許單獨的程式設計師們去編寫測試程式碼。還有一些允許單獨的程式設計師們去編寫抽象類和介面。也還有一些只是簡單的允許程式設計師們決定什麼時候最好需要成對。有一件事是很清楚的，無論如何——研究已經表明當實踐成對程式設計的時候錯誤率會很顯著地降低。 

有一些人不喜歡成對 

--------------------------------------------------------------------------------

一些人對成對程式設計的概念感覺不適應。在我們的經驗中，這些人實際上在嘗試了一週左右後發現他們的不適應消失了，並且他們喜歡成對和發現它是很用處的。只有很少的人會繼續不喜歡這個實踐。因此，對大多數人來講，嘗試並且習慣它是一個很簡單的問題。對於那些真正了嘗試過並且依然感覺到不適應這個實踐的人們，團隊就必須去找到一些適合他們做的事情。 


裝置，方便以及後勤


顯示器和鍵盤的佈置 

--------------------------------------------------------------------------------

裝置的佈置對成功的成對實踐是很重要的。如果夥伴們不能坐到彼此的旁邊並且很快的交換鍵盤的話一個成對很難實施得很好。規則是：你必須能夠來回的拿到鍵盤和滑鼠而不需要交換座位。 

最好的安排通常是一個漂亮的長平板桌。將顯示器放在中間然後正對著顯示器放兩把椅子。坐下來讓顯示器在你們之間。確保很容易能在你們之間挪動鍵盤和滑鼠。同時確保在你拿到鍵盤的時候，你能夠很舒適並且能夠坐直。確保顯示器能夠讓兩個夥伴都看得清楚而不需要轉動它。 

大房間 

--------------------------------------------------------------------------------

為了便於交換成對的夥伴，一般都希望能夠在一個類似棒球候補球員區的環境下工作。在一個房間裡放置多個成對用的工作站。使用有輪子的椅子和油布或者瓷磚地板。排列工作站讓成對的夥伴們都能面對面。這樣做的目的是為了增加交流。有些時候最重要的交流就是那些偶然發生的。我們想讓這種交流出現的機率能夠增加。 

在角落裡 

--------------------------------------------------------------------------------

現今的許多小單間都將工作站放置到角落裡。程式設計師們面對著角落坐下來在他或她的面前是一個顯示器。當然這樣會便於單人工作，但是在這種環境下成對程式設計幾乎是不可能的。如果你有一個將工作站放在角落的小單間，那麼在其他地方放置一些成對用的工作站——也許在一個會議室。在一個會議桌上使用一個膝上型電腦進行成對程式設計常常是很有效的方式。 


問題和關注

成對讓生產力減半 

--------------------------------------------------------------------------------

這種說法建立在以下的理由上，兩個人在一個任務上一起工作會消耗兩倍於一個人在同樣的任務上工作的所花費的時間。這看上去合情合理，但這卻並不是真實情況。根據研究(參考資料2?)表明很少的，即便有，生產力會在成對工作的情況下喪失。同樣的研究證明了成對可以大大的降低錯誤率，以及程式程式碼的大小，同時極大地增加了工作的樂趣。 

成對夥伴間的爭論 

--------------------------------------------------------------------------------

任務的所有者有所有設計爭論的最終決定權，但是處理爭論的最好的方式是對兩種設想都進行嘗試並選擇工作得最好的那種。 

專家 

--------------------------------------------------------------------------------

傳統的至理名言給出的建議是對某一個特殊領域有專長的程式設計師，例如資料庫或者圖形使用者介面，應該獨自在這些領域發揮作用。但是在一個成對程式設計的環境下，這些專家成為那些沒有這方面特長的夥伴的最好的導師。程式設計師們可以簽上一個不在他們的專長領域範圍內的任務然後徵求專家們的幫助。這樣，專家的知識就開始在整個團隊的範圍內傳播，極大的減少了專案反覆的程式。 

噪音 

--------------------------------------------------------------------------------

一個成對地夥伴可能在他們程式設計時產生噪音。一個坐滿成對夥伴的大房間會保持頻繁的低低的嗡嗡聲。有人會感覺到這些噪音令人煩悶以及分散注意力。這並不能證明是一個重大的問題。如果你覺得這些噪音令人煩悶，你可以走到會客室坐一會兒。 

牛仔 

--------------------------------------------------------------------------------

許多團隊會發現他們是一到兩個牛仔式編碼者的足以自豪的擁有者。這些牛仔是一些比其他任何都能更快地完成任務，不能和其他人合作，並且任何人都不被允許（或者是如果允許的話，也沒有能力）去閱讀他們的程式碼。對於這些開發者最好的處理方法是讓他們離開專案或者承擔一個不需要他們編寫產品程式碼的角色。也許他們能夠編寫一些臨時的工具或者做一些瘋狂折磨式的測試工作。 

習慣障礙和障礙形式 

--------------------------------------------------------------------------------

有一些人使用QWERTY式的鍵盤。另一些人更習慣於DVORAK式的。一些人需要特製的鍵盤，滑鼠，顯示器，腳踏開關，等等，等等。一些人在程式設計時不能沒有耳機和喧鬧的音樂。另一些人必須在他們周圍擺滿空箱子。一些人喜歡用emacs編輯器。另外一些人喜歡VI。甚至還有一些人喜歡用WordPad?. 

實際上，這些可以指出的障礙是數不清的。但是每一種障礙和每一個人都可以通過一些想法解決並且有辦法進行折衷。一個讓這些事情阻止他們的團隊是不可能在他們嘗試的任何努力中取得成功的。 

團隊如何規劃成對的計劃？ 

--------------------------------------------------------------------------------

我們並不認為任務需要指定給一個雙人組。更好的方式時每一個開發者需要承擔一些任務的責任。我們喜歡非正式地成對。每一個開發者，從事他或她自己承擔的責任，請求其他開發人員提供暫時的幫助。任務的所有者保持著所有權和責任。成對的夥伴僅僅是幫忙的人。 

每一個開發者必須在評估任務的時候計入他或她作為其他人的開發夥伴的時間。 


總結

成對程式設計是一種成功試驗過的，令人滿意的程式碼審查的替代方法。不僅如此，它還是一種編寫軟體系統的革新的途徑。帶來的好處也不僅限於生產力和質量，而且對一些像團隊士氣和精神風貌等方面帶來好的影響。 

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