極限編程中結對編程的不良現象分析及對策

嚴悍　苑俊旺　邵帥　趙學龍

摘要：結對編程是極限編程的特色實踐之一。在極限編程活動中，對于中國學生，結對編程是組織難度最大的活動。為了更有效地組織結對編程，文章分析以往團隊成員所出現的一些不良現象，并探討可行對策，為大學軟件實踐教學和軟件業者從事極限編程提供參考和指導。

關鍵詞：結對編程；極限編程；敏捷軟件開發；人為因素

0 引言

結對編程（pair programming）是極限編程（XP，eXtreme Programming）和敏捷軟件開發方法學的特色實踐之一。對于我國學生，組織極限編程活動，采用結對編程方法，有助于溝通能力、口頭表達能力的培養，有助于相互學習、相互支持，有助于團隊協作能力的培養，有助于提高軟件質量和開發效率。因此結對編程實踐具有非常重要的意義。

筆者詳細分析了結對編程中學生所表現出來的不良現象，并針對這些現象給出相應對策，以改進極限編程活動的效率。

1 結對編程的不良現象

一個項目團隊成功或失敗的關鍵原因往往不是技術因素，很多非技術的人為因素在起作用。極限編程活動中，如何組織結對編程就是非常突出的人為因素。筆者曾參與德國波恩大學2屆XP活動，在國內組織了4屆XP活動?；顒又邪l現傳統軟件工程中的一些習慣做法，以及學生的一些習性，導致活動中出現了一系列問題，在價值觀、團隊行為等多個方面都產生了明顯沖突，導致結對編程在國內“水土不服”。

沖突1，傳統軟件工程中，往往先劃分模塊，然后個人對模塊負責。這種做法看似責任明確，但實際上，項目依賴每個成員，當某個成員離職，該模塊就無法維護，導致項目風險增大。此種做法與極限編程所倡導的“代碼集體所有權”違背。

代碼集體所有制，即每個人都是項目中所有代碼的受益人，同時也是責任人。每個人對所有代碼負責，而不是僅對自己編寫的代碼負責；每個人要對所有代碼的將來的維護負責；而不是僅對當前運行負責；每個人提交的代碼都屬于團隊，允許他人質疑、修正、重構，甚至拋棄重建。

國內學生大多過度關注個人能力和個人成績，而往往忽略團隊能力和團隊成績，他們往往傾向于獨立研究解決問題。獨立學習能力往往作為衡量學生個人能力的標尺，從小學到大學的教育都如此，根深蒂固，短時間內難以改變。

沖突2，傳統軟件工程中，多人分別完成任務，看似并行工作，效率應該更高，但實際上返工較多。原因是個人獨立完成一個模塊的設計、編程和測試，實際上往往導致需求誤解多、缺乏設計合理性、缺乏測試完備性，最后導致軟件質量達不到要求，項目開發效率降低。

國內學生常常質疑這樣的問題，兩個人用一臺電腦編程，怎么可能比兩人用兩臺電腦并行編程更有效？

結對（pair）是最小的團隊。結對編程要求兩人自由組成一個結對來完成一項任務，要求坐在一起用一臺電腦。兩人分別扮演兩個角色：正駕driver和副駕co-driver或領航員，就像汽車拉力賽中兩人共同駕駛一部汽車。正駕操鍵盤，負責編碼，副駕掌鼠標，負責指導方向并做代碼審查；正駕注意力往往集中在最鄰近目標上，如前方400米之內的具體目標，而副駕能借助地圖（如模型或文檔）來指導更長遠目標。兩人不斷溝通交流，密切協作，共同抵達目標。

兩人每小時休息一次并更換角色，直到一項任務完成，任務完成之后，結對解散，對新的任務再組織新結對。一個項目完成后，每個人都應與其它成員至少結對一次。

對于一個項目團隊來說，最理想情形是，一個人的成功經驗就是整個團隊的經驗，一個人在某個地方失敗或走彎路，整個團隊都不會再出現。

沖突3，傳統軟件工程教育中，指導教師或項目負責人往往要起過分重要的權威作用。因為學生往往只關注老師如何評價，而往往忽視團隊其他成員的意見或建議。當團隊成員之間出現錯誤或不一致，就難以協調自行解決問題，除非指導教師干預。極限編程中，尊重是極限編程核心價值觀之一。要尊重每個人的意見，而不僅僅是教師或項目負責人。

2 不良現象分析及對策

文章就結對編程活動中成員所出現的7種不良現象進行分析，并給出相應對策。

1）高手單駕，副駕休閑。

編程能力強的學生往往傾向于單獨行事，高手單獨駕車，很忙很累，而副駕無事可做，導致人力資源浪費。解決對策是堅持每小時更換角色，共同駕駛，共同抵達目標。個人能力有高低差異，高手有責任主動介紹經驗和技能，把更多機會給另一方，另一方應主動提出問題，尋求解決，主動駕駛。

2）事后證明。

副駕不同意正駕選擇或未達成一致，正駕就獨自到達目標，先造成即成事實，“一夜之間”獨自解決難題，以此證明自己正確高明。這樣對另一方可能造成潛在矛盾，并未達到結對編程之目的。解決對策，副駕作為領航，應先決定做什么，正駕再執行。

3）成功自尊。

很多學生只希望別人看到自己成功的結果，不希望別人看到過程中的多次失敗。這種“要面子”心理和“結果證明成功”做法導致過程中交流被動，團隊效率降低。解決對策，鼓勵失敗和失敗共享。具體做法是，建立失敗表彰機制，鼓勵個人發布自己遇到的錯誤和失敗，發布“有效失敗”記錄，說明發生時間、錯誤或失敗現象以及原因和解決辦法，標明撰寫人、重寫人。并將記錄發布在團隊網頁上，使所有成員能及時看到?！坝行　钡拿恳粋€錯誤或失敗都有特色、不重復，對所有成員都有參照價值。對于一個錯誤，如原因不明，相同錯誤可能再次發生，對于多次發生的錯誤需要團隊格外重視，如果原因已清楚，相同錯誤就不應再犯。一名成員發現錯誤后，不鼓勵私下自行解決，因為這樣對其它成員并沒有經驗積累。在每個開發周期之后應累計錯誤記錄次數。對累計次數最多的個人進行鼓勵表彰。鼓勵失敗是極限編程最具顛覆j生的特點之一，測試優先和測試驅動開發也有鼓勵失敗的動機。

4）情面阻礙。endprint

學生在發現別人編碼有錯誤時，不好意思指明，更不好意思修改或重構他人代碼，導致錯誤和缺陷不能及時發現和處理，進一步可能導致項目延誤或重大缺陷。解決對策，勇氣是極限編程核心價值觀之一，要求每個人共同擔責，貫徹代碼集體所有制，將所有共享代碼都看作是自己的編碼。項目負責人應明確當發生錯誤或缺陷時，不僅應追查誰做的編碼，還應追查誰可能已經發現了錯誤而沒有說明的責任人。

5）不熟悉難結對。

只與相熟的人結對，而對陌生人難以有效交流，難以組成結對。團隊中可能有外國學生，也可能是本科生、研究生混搭，大部分相互間不熟悉，導致部分成員在執行任務時形成隔閡。解決對策，成員應明確與陌生人有效溝通是一種極其重要的能力，應格外重視這種能力的培養，一些集體配合游戲項目有助于成員之間增強交流和協作。

6）個人偏見。

對技術方案見解或意見不一致而產生個人偏見，進而導致對某成員“看不慣”“合不來”，從而采取不合作態度。如果團隊中兩個重要成員形成個人矛盾，那么整個團隊就會受到影響。解決對策，編程是一種創作，創作都帶有個人色彩，編程作為軟件工程活動，個性發揮應受到限制。讓團隊成員知道，可爭論，但反對爭吵；可公開爭論，但反對私下言論和個人偏見。每個迭代周期結束后，成員都應回答“對你幫助最多的同學是誰？”，以促進相互學習，交流經驗。

7）延誤借口。

學生編程往往要使用別人已完成的編程，但發現別人編程有問題或缺陷，而沒有及時地、明確地提出，并以此為借口，延誤了自己的任務，并把延誤責任推給別人。另一種情形為起初使用他人編程正確，后來他人出于糾錯或重構目的而修改了編碼，導致自己編碼錯誤。以此為借口，延誤了自己的任務。解決對策，項目負責人應明確指出這是不可容忍的行為，成員應明確每個人的編碼都會被他人使用。

3 相關討論

結對編程目前獲得廣泛關注并給予好評。文獻[3]通過實踐指出結對編程可減少15%的開發時間。文獻[4]說明組織大學生結對編程，獲得定性和定量的評價和度量，結果都是積極的。但軟件業開發者則提出更多更尖銳問題來探討。

文獻[5]指出結對編程對于軟件工程的好處和缺點，其中大多缺點是針對中國軟件開發團隊。例如個人編程習慣不同可能導致難以協調；爭論中各執己見，互不讓步。應關注結對副作用，如談論內容與工作無關，合伙應付敷衍等現象分析。文獻[6]給出結對編程中的一些成型的模式，一個結對中的兩個角色，正駕和副駕，對于不同人員的行為特征，給出解決辦法。最主要的是，在一個結對中，當某人行為出現某種現象時，就應及時轉換角色。

文獻[7]探討了何時結對編程最有效的問題。前提是具體考慮任務（稱為挑戰）難度和個人技能之間是否匹配。結對編程有流模式與指導兩種成功模式，流模式就是兩人技能與任務難度之間都匹配，分工協作完成任務；指導模式是針對新手完成較簡單任務，需要老手指導，讓新手有機會學到經驗。結對編程還有兩種不成功模式，“經驗浪費”和“不知所措”?！敖涷灷速M”模式是任務太簡單，而無需老手指導，此時如果強行結對編程，就會導致浪費人力；“不知所措”模式是另一個極端，任務太復雜或需要太多新知識，最后無力完成。

4 結語

結對編程在我國仍處于探索階段。盡管目前存在種種不良現象，但也存在多種途徑和方法。（1）活動組織者只要認識到這些不良現象背后的原因，就容易找到合理的解決辦法。（2）在活動之初通過培訓告知參與者注意事項。（3）在活動中各個迭代周期小結時組織者應及時指出所發現的不良現象。（4）對“失敗”鼓勵和獎勵，這種觀念轉變也很重要。

參考文獻：

[1]Beck K，Andres C.解析極限編程：擁抱變化[M].2版 雷劍文，譯.北京：機械工業出版社，2011：42-55.

[2]Martin R C.敏捷軟件開發——原則、模式與實踐[M].鄧輝，譯.北京：清華大學出版社，2003：9-20.

[3]Cokburn A.The costs and benefits ofpair programming[J].Extreme programming examined，2000（8）：223-247.

[4]Williams L，Kessler R R，Cunningham W，et al.Strengtheningme caseforpairprogramming[J].Software，IEEE，2000，17（4）：19-25.

[5]陳皓.結對編程的利與弊[EB/OL].（2010-03-15）[2013-9-4].http：∥kb.cnblogs.com/page/58732/.

[6]Pairprogramming stereotypes[EB/OL].（2011-12-27）[2013-9-1].http：∥www.planetgeek.ch/2011/12/27/pair-programming-stereotypes/.

[7]Pair programming：to do or not to do[EB/OL].（2008-12-10））[2013-09-04].http：∥softwarecreation.org/2008/pair-programming-to-do-or-not-to-do/.

（編輯：趙廓）endprint