跳至內容

結對程式設計

本頁使用了標題或全文手工轉換
維基百科，自由的百科全書
結對程式設計

結對程式設計（英語：Pair programming）是一種敏捷軟件開發的方法，兩個程式設計師在一個電腦上共同工作。一個人輸入代碼，而另一個人審查他輸入的每一行代碼。輸入代碼的人稱作駕駛員，審查代碼的人稱作觀察員（或導航員）[1]。兩個程式設計師經常互換角色。

在結對程式設計中，觀察員同時考慮工作的戰略性方向，提出改進的意見，或將來可能出現的問題以便處理。這樣使得駕駛者可以集中全部注意力在完成當前任務的「戰術」方面。觀察員當作安全網和指南。結對程式設計對開發程式有很多好處。比如增加紀律性，寫出更好的代碼等。

結對程式設計是極限編程的組成部分。

成本和收益

[編輯]

一些研究發現程式設計師結對工作與單獨工作相比，會寫出更短的程式，更好的設計，以及更少的缺陷。[2] 研究發現缺陷率降低15%到50%，會由於程式設計師的經驗以及任務的複雜度而不同。[3][4] 結對程式設計比單獨程式設計相比，通常會考慮更多的設計選項，達成更簡單，更易維護的設計；程式設計師們也會更早地捕捉到設計的缺陷。[5] 與一個程式設計師承擔同一個任務相比，程式設計師在結對程式設計時工作會完成的更快。結對的程式設計師經常發現當他們一同工作時解決表面上「不可能」的問題變得容易，或更加快速，或至少有可能解決。[2][6]

然而，一個2007年的元分析得出結論「結對程式設計並非一致地有利或有效的」，這是因為是否結對程式設計選擇以外的許多因素在程式設計任務的產出上起着很大的作用。[7] 元研究發現結對程式設計往往一定程度地縮短了開發時間，而且對代碼質素產生了正的邊際效益，但是結對程式設計大大增加了開發人員的工時；也就是說與單獨程式設計相比花費大大增加了。作者指出有關結對程式設計的研究遭遇了發表偏倚，有些不利於結對程式設計的研究要麼沒有開展研究，要麼沒有投稿，要麼沒有被授受發表。他們得出結論「你不可能期待又快又好又便宜。」

雖然編碼通常比一個程式設計師單獨工作更快地完成，但是整體程式編寫時間（程式設計師數目 × 花費的時間）增加了。管理者需要在工作更快的完成以及縮減測試和除錯時間和更高的編碼成本之間平衡。這些因素的相對權重在不同的專案、不同的任務之間也不同。對於那些程式設計師沒有完全理解的任務上，程式設計師期待更多的創造性、挑戰、以及高複雜度，此時使用結對程式設計最有幫助。[8] 在簡單的，程式設計師都完全了解的任務上，結對程式設計導致生產力的淨下降。[8][9]

在兩個程式設計師工作時，兩個程式設計師之間傳遞着知識。他們分享關於系統細節的知識，並且互相學習程式設計技巧。[2][10] 新的員工很快地獲得團隊的習慣，並學習到系統的細節。[11] 「混雜結對程式設計」，即每個程式設計師輪流與團隊中的所有其他程式設計師結對程式設計，而不是僅與某個程式設計師程式設計，使得系統的知識在整個團隊中傳播，減少了程式設計師離開團隊帶來的風險。[2]

結對程式設計通常會帶來紀律和時間管理的提升。程式設計師在與結對的夥伴一同工作時，不太會忘記編寫單元測試，花時間上網或處理個人電子郵件，[12] 或偷工減料。結對的夥伴「讓他們保持誠信」。[13][14] 人們更不願意打斷兩個結對程式設計的人，而單獨工作的人卻容易被打斷。[15]

其他的收益據報告包括提高士氣[16]以及在代碼正確性上更大的信心。[2]

可重複實驗

[編輯]

在學術圈裏，結對程式設計也是爭議的。其原因是過往學術期刊所發表的結對程式設計實驗，基本上其他學者很難讓重複實驗核對。所以很多結對程式設計實驗只有原作者才真正了解結果。可是，2013年Giri 和Soni [17] 重複了在2006年Kim Man Lui所報告的結對程式設計實驗 [18] 而實驗結果也是一致。此次重複實驗標記着結對程式設計研究的里程碑。

變體

[編輯]

遠端結對程式設計

[編輯]

遠端結對程式設計，也稱作虛擬結對程式設計或分散式結對程式設計，是指兩個程式設計師不在同一地點，通過協同編輯器，共用桌面，或遠端結對程式設計的IDE外掛程式進行的結對程式設計，[19]。 遠端結程式設計引入了一些在面對面的結對程式設計中不存在的困難，例如協同運作的額外時延，更多的依賴「重量級」的任務跟蹤工具，而不是「輕量級」的索引卡片，以及沒有口頭交流導致的在類似誰「控制鍵盤」問題上的混亂和衝突[20]

許多工具，例如Eclipse有外掛程式支援遠端結對。有些團隊嘗試使用VNC和RealVNC，每個程式設計師使用他們自己的電腦。[21][22][23] 也有人使用基於文字的GNU Screen的對談共用功能。蘋果公司的Mac OS X包含內建的螢幕共用應用。

乒乓結對程式設計

[編輯]

在乒乓結對程式設計中，觀察者編寫失敗的測試用例，駕駛者修改代碼以通過該用例，觀察者編寫新的單元測試用例，等等。這個迴圈持續到觀察者能不寫出失敗的測試用例為止。但是這種方法比估計的計劃要花更多的時間。[24]

參見

[編輯]

參考文獻

[編輯]
  1. ^ Williams, Laurie. Integrating Pair Programming into a Software Development Process (PDF). 14th Conference on Software Engineering Education and Training. 2001: abstract [2020-09-16]. （原始內容存檔 (PDF)於2011-12-29）. "One of the programmers, the driver, has control of the keyboard/mouse and actively implements the program. The other programmer, the observer, continuously observes the work of the driver to identify tactical (syntactic, spelling, etc.) defects, and also thinks strategically about the direction of the work."
  2. ^ 2.0 2.1 2.2 2.3 2.4 Cockburn, Alistair; Williams, Laurie. The Costs and Benefits of Pair Programming (PDF). Proceedings of the First International Conference on Extreme Programming and Flexible Processes in Software Engineering (XP2000). 2000 [2011-03-22]. （原始內容存檔 (PDF)於2016-12-17）. 
  3. ^ Canfora, Gerardo; Aniello Cimitile, Felix Garcia, Mario Piattini, Corrado Aaron Visaggio. Evaluating performances of pair designing in industry (PDF). The Journal of Systems and Software. 2007, 80 (80): 1317–1327 [2010-06-14]. doi:10.1016/j.jss.2006.11.004. （原始內容存檔於2016-03-06）. 
  4. ^ Agility counts. The Economist. September 20, 2001 [2011-03-22]. （原始內容存檔於2016-07-09）. .
  5. ^ Williams, Laurie; Kessler, Robert. Pair Programming Illuminated. Addison-Wesley. 2003: 27–28. ISBN 0-201-74576-3. With pair programming, 'four eyeballs are better than two,' and a momentous number of defects are prevented, removed right from the start. These continual reviews outperform traditional, formal reviews in their defect-removal speed. 
  6. ^ Williams, Laurie; Kessler, Robert. Pair Programming Illuminated. Addison-Wesley. 2003: 26. ISBN 0-201-74576-3.  "Collaborative teams consistently report that together they can evolve solutions to unruly or seemingly impossible problems. … The driver might actually be working out a design or implementing a part of the problem, realizing that he or she may ultimately come to a dead end in the problem resolution. The navigator, while watching the driver's partial design or implementation, begins thinking about the next step. When the driver hits the dead end, the navigator is often prepared to take over and lead the way. Often, the cycle continues until the problem is solved."
  7. ^ Hannay, Jo E.; Tore Dybå, Erik Arisholm, Dag I.K. Sjøberg. The Effectiveness of Pair Programming: A Meta-Analysis. Information and Software Technology. July 2009, 51 (7): 1110–1122. doi:10.1016/j.infsof.2009.02.001. 
  8. ^ 8.0 8.1 Lui, Kim Man; Keith C. C. Chan. Pair programming productivity: Novice-novice vs. expert-expert (PDF). International Journal of Human-Computer Studies. September 2006, 64 (9): 915–925 [2008-07-21]. doi:10.1016/j.ijhcs.2006.04.010. （原始內容 (PDF)存檔於2011-07-20）. 
  9. ^ Arisholm, Erik; Hans Gallis, Tore Dybå, Dag I.K. Sjøberg. Evaluating Pair Programming with Respect to System Complexity and Programmer Expertise. IEEE Transactions on Software Engineering. February 2007, 33 (2): 65–86 [2008-07-21]. doi:10.1109/TSE.2007.17. （原始內容存檔於2009-01-11）. 
  10. ^ Williams, Laurie; Kessler, Robert. Pair Programming Illuminated. Addison-Wesley. 2003: 29. ISBN 0-201-74576-3.  "Knowledge is constantly being passed between partners, from tool usage tips to design and programming idioms. The partners take turns being the teacher and the student. Even unspoken skills and habits cross partners."
  11. ^ Williams, Laurie; Kessler, Robert. Pair Programming Illuminated. Addison-Wesley. 2003: 112. ISBN 0-201-74576-3.  "[Expert-novice pairing] can even be valuable for novices who are novices only in the sense that they haven't been with their team for very long. … Watching and then doing with an expert by your side can greatly reduce the time it would require to learn 'the right way' of working with the team. It really helps when the newbie works with many of the experts (or with any team member) so he or she can learn about many different aspects of the system."
  12. ^ Williams, Laurie; Kessler, Robert. Pair Programming Illuminated. Addison-Wesley. 2003: 23. ISBN 0-201-74576-3.  "Two people working in a pair treat their shared time as more valuable. They tend to cut phone calls short; they don't check e-mail messages or favorite Web pages; they don't waste each other's time." (Ward's Wiki 1999, contributed by Paul Chisholm).
  13. ^ Beck, Kent. Extreme Programming Explained. Addison-Wesley. 2000: 102. ISBN 201-61641-6 請檢查|isbn=值 (幫助). "Under stress, people revert. They will skip writing tests. They will put off refactoring. They will avoid integrating. With your partner watching, though, chances are that even if you feel like blowing off one of these practices, your partner won't."
  14. ^ Williams, Laurie; Kessler, Robert. Pair Programming Illuminated. Addison-Wesley. 2003: 24. ISBN 0-201-74576-3. "With any software development process there is a constant struggle to get the software engineers to follow the prescribed process. A benefit of pair programming is improved adherence to procedures and standards."
  15. ^ Williams, Laurie; Kessler, Robert. Pair Programming Illuminated. Addison-Wesley. 2003: 24. ISBN 0-201-74576-3. "Others see us already working with someone else, and they leave us alone. The net effect is that we have bigger blocks of uninterrupted time, which is good for our mental state and our progress. It also reduces task-switching, which for some people generates a huge overhead."
  16. ^ Williams, Laurie; Kessler, Robert. Pair Programming Illuminated. Addison-Wesley. 2003: 21. ISBN 0-201-74576-3.  "In our recent Web survey, we asked, 'What have you found beneficial about pair programming?' The single most common response was, 'It's a lot more fun!'"
  17. ^ Giri, Manisha. Effectiveness of Software Development Process Using Programmer Ranker Algorithm in Pair Programming (PDF). International Journal of Engineering Sciences and Research Technology. June 2013, 2 (6): 1524–1535 [2013-10-30]. （原始內容存檔 (PDF)於2013-10-31）. 
  18. ^ Lui, Kim Man. Pair Programming: Issues and Challenges (PDF). Agile Software Development: Current Research and Future Directions. 2010: 143–163 [2013-10-30]. （原始內容 (PDF)存檔於2013-11-01）. 
  19. ^ Flor, Nick (2006). Globally distributed software development and pair programming. Communication of the ACM, 49, 57-58.
  20. ^ Schümmer, Till; Stephan Lukosch. Understanding Tools and Practices for Distributed Pair Programming (PDF). Journal of Universal Computer Science. September 2009, 15 (16): 3101–3125 [2010-04-30]. （原始內容存檔 (PDF)於2016-12-03）. 
  21. ^ Agile Ajax: Pair Programming with VNC 互聯網檔案館的存檔，存檔日期2008-04-02.
  22. ^ Pair Programming - The Ultimate Setup and the other options we tried. - Jonathan Cogley's Blog. [2011-03-22]. （原始內容存檔於2014-01-02）. 
  23. ^ Ola Lindberg › Computer ergonomics and pair programming. [2011-03-22]. （原始內容存檔於2009-07-21）. 
  24. ^ PairProgrammingPingPongPattern. c2.com. [2011-03-22]. （原始內容存檔於2016-07-30）. 
取自 "https://zh.wikipedia.org/w/index.php?title=结对编程&oldid=79285375"