结对编程

结对编程（英語：）是一种敏捷软件开发的方法，两个程序员在一个计算机上共同工作。一个人输入代码，而另一个人审查他输入的每一行代码。输入代码的人称作驾驶员，审查代码的人称作观察员（或导航员）[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. (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. Cockburn, Alistair; Williams, Laurie. (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. (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. . The Economist. September 20, 2001 [2011-03-22]. （原始内容存档于2016-07-09）..
  5. Williams, Laurie; Kessler, Robert. . 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. . 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. . Information and Software Technology. July 2009, 51 (7): 1110–1122. doi:10.1016/j.infsof.2009.02.001.
  8. Lui, Kim Man; Keith C. C. Chan. (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. . 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. . 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. . 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. . 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. . 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. . 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. . 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. . 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. (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. (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. (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. . [2011-03-22]. （原始内容存档于2014-01-02）.
  23. . [2011-03-22]. （原始内容存档于2009-07-21）.
  24. . c2.com. [2011-03-22]. （原始内容存档于2016-07-30）.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.