转:结对编程的误区

标签: Misc | 发表时间:2012-02-29 21:15 | 作者:gouki
出处:http://www.neatstudio.com/

结对编程在我们现在的工作中真的没有使用这玩意。极限编程也没有用到,我们还是安稳的在一步一步的开发。。。但不代表我们没有尝试过。
其实,在07年的时候,那时候和一哥们就尝试过结对,效率确实上升了不少,但后来仔细想想,正由于两个人水平相近,这样的结对却没有真正带来了效率上升,反而还不如两个人单独开发,事后合并代码。虽然有一些BUG,但总体代码却多写了很多。再过了一段时间,也是和一朋友结对,但效率更低,因为两个人的水平不一致,水平高的受不了水平低的一些低级错误,水平低的却看不明白水平高的在做什么。痛苦。。。后来就放弃了这种想法。
以下是原文:http://www.cnbeta.com/articles/174866.htm
在过去的几年里,我有过许多结对编程的经历。有时在我的团队里进行,有时在客户那里,有时在coding dojo(一种编程模式,几个程序员一起合作完成一个任务),有时在我的开源项目里。对于那些知道如何结对编程的程序员来说,这种模式很棒,很高效。
但是你不能指望在两个程序员面前摆台电脑,就指望他们一开始就做得很棒。结对编程需要学习,程序员需要知道实施者(敲键盘的人)和领航员之间的区别。下面来看看些细节。

在结对编程中,我遇到了一些误区,列在下面。
一、领航员误区
1. 发号施令者
喜欢发号施令的人总是对敲键盘的人说:“到末行,加个反括号,然后…”。他不去关注解决方法和下一步该怎么做,而过度关注一些编程细节。
事实上,他希望他自己来掌控键盘。所以当你碰到一个喜欢发号施令的人,那么将键盘交给他吧,转换领航员的角色。
2. 拼写纠错者
拼写纠错者坐在你旁边,纠正你输入的每个错误字符。当然,他没有时间来真正的进行导航。
和纠错者商量一下,当他给你纠错的时候让他请你喝一杯咖啡(或者任何你想要的东西)。
3. 吹毛求疵者
吹毛求疵者会指责你写的每行代码。当他的意见正确时,他会一意孤行,不用你已经写好的代码,而完全照着他的想法。
就如自由爵士音乐人都是复用其他乐队成员的音符,来构造成一首曲子一样,好的结对编程也应基于现有的基础上进行推进。
试着转换角色,也许吹毛求疵者就会变成一个目中无人的人。
4. 默不作声者
默不作声者是那些几乎不发表意见的人。他仅仅坐在那里看着你工作。
试着问下他对你的方法有什么意见,或者问他下一步该写什么测试代码。
5. 心不在焉者
心不在焉的人企图让你分心,而不是提供给你有建设性的意见,帮你解决问题。
那么让他离开吧,比起一个让自己分心的人而言,不如一个人编程。
二、实施者误区
1. 深藏不露者
深藏不露者仅仅自己敲着代码而不告诉别人他在做什么。领航员不得不靠自己去弄懂代码。关于该用什么方法,该选择哪种设计,领航员和实施者之间完全没有交流。
领航员需要问问深藏不露者关于他的计划或想法。
2. 目中无人的人
目中无人的人通常忽略领航员的所有建议,大多数是因为他们觉得自己的想法或编程技能更胜一筹。
当碰到一个目中无人的人时,立即停止结对编程吧,开始下一个任务吧。自大的人往往也不会是个好的领航员。他们很可能变成发号施令者或是吹毛求疵者。
3. 不知所措的人
不知所措的的人往往不习惯结对编程,非常紧张,不能掌控全局。
确保自己的领航员角色做到最好。小心的提出意见,对于不知所措的人主要给予鼓励。
但是,大多数程序员开始都是这种情况。所以,不要对他们的结对编程期望太高。让他们首先成为一个领航员,或者让能够很好的处理人际交往问题的领航员在他们旁边。
4. 跳跃性很大的人
跳跃很大的人喜欢在代码中进行大范围的跳跃,这样领航员不知道进行到哪里了。
领航员需要让他慢下来,问他关于他的计划,并确保自己比他知道更多的快捷键。
5. 不熟悉工具的人
不熟悉工具的人不知道开发环境的快捷键,效率非常低。
交换角色吧,让他看看你的技巧。或者打印一张印有快捷键的cheat sheet。
我相信还有其他的误区,如果你有什么想法请写在评论留言吧。
原文: planetgeek.ch  编译: 伯乐在线
----EOF---
如果上面的事情真的是真的,那证明我们还是有问题,在结对编程的处理上。但我真不敢尝试了。哎

相关 [结对编程] 推荐:

敏捷结对编程实践

- - 技术改变世界 创新驱动中国 - 《程序员》官网
本文主要从提升项目质量、促进知识传递及减少项目风险等角度出发,讲述作者所在团队在结对编程实践中的一些经历,以及如何避免或减少其所带来的负面影响. 也许你还未曾尝试甚至还不曾了解,那么我们一起来学习和了解敏捷结对编程实践,相信对敏捷感兴趣的你会有收获. 结对编程(Pair Programming)是一种敏捷软件开发实践,指两个程序员并排坐在一台电脑前,面对同一个显示器,使用同一个键盘和鼠标一起工作.

转:结对编程的误区

- - 膘叔
结对编程在我们现在的工作中真的没有使用这玩意. 极限编程也没有用到,我们还是安稳的在一步一步的开发. 其实,在07年的时候,那时候和一哥们就尝试过结对,效率确实上升了不少,但后来仔细想想,正由于两个人水平相近,这样的结对却没有真正带来了效率上升,反而还不如两个人单独开发,事后合并代码. 虽然有一些BUG,但总体代码却多写了很多.

结对编程——我的噩梦

- - 博客园_知识库
   英文原文: Pair Programming - My Personal Nightmare.   自从 极限编程诞生起,我就一直在听说结对编程是个 好东西. 所有的敏捷传教士们都在告诉我们:结对编程能提高代码质量,有助知识共享,甚至激发开发效率,同时,还能深度拉近程序员之间的感情关系(参看 拥抱编程).

结对编程的价值及注意点

- - Juven Xu
结对编程( Pair Programming)可能是最受争议一项的敏捷实践,持续集成和重构基本已经普遍被大家认同了,TDD还能引发 很大的口水仗,倡导结对编程则有被狂砸砖头的风险,本文我不想说结对编程绝对有多好,我想分享的是一些有关结对编程我体验和观察到的价值,以及几个我认为特别需要注意的地方,尤其是后者, 如果以错误地方式用结对编程,弊很可能大于利.

结对编程成为主流,但反响冷淡

- - InfoQ cn
华尔街日报开始注意到越来越多的技术公司在实践结对编程,并在题为“ 计算机程序员在共享中学到深刻教训”的文章中发表了自己的看法. 在技术公司中,结对寻找到了支持者. 这些公司包括Facebook和移动支付创业公司Square. 结对的倡导者对结对的力量赞不绝口,声称结对程序员可以捕获不采用结对时需要花很大代价才能找到的软件错误,而且不太可能花时间上网冲浪.

变化是如何产生的——有关结对编程

- - Juven Xu
一个十多人的团队,十个月前,每个人都习惯在自己的一块自留地代码上劳作,当管理层推结对编程时,大部分人反应冷漠甚至抵触. 今天,这个团队的几乎所有人都愿意接受结对编程这种工作方式,各个人对整个系统的了解更好了,遇到不熟悉的地方都很自然地想到找个熟悉的人来结对,很自然的,团队合作更好了. 然而,同样的公司,不是所有的团队都有这样的变化, 自留地式的工作方式在一些团队非常普遍,这是为什么.

结对编程 VS 代码审查:对比开发者文化

- - ITeye资讯频道
从上一份工作到现在的这份工作,我从结对编程的开发文化过渡到同行代码审查,这个转变过程是一个非常有趣的经历. 我认为我要记录下些我所注意到的变化. 你可以找到很多标题是/(结对编程|代码审查)的(利|弊)/这种样式的文章,这些文章的作者都可以给出一套清晰且有说服力执行方案. 我认为只要权衡它们的利弊,这两种方案都是非常有效率的.

作为程序员, 你结对编程过吗?(结对编程的意义,经济学价值和个人看法)

- 華 - 博客园-首页原创精华区
在此模式下,一对程序员并肩作战,平等互补进行开发工作. 两个程序员并排坐在一台电脑前,同对一台显示器,使用同一个键盘,同一个鼠标进行工作. 一起分析,一起测试,一起设计,一起编程. 那么结对编程中两个人如何扮演角色. 驾驶员是控制键盘输入的人,而领航员是起到领航,提醒的作用. 你说工程量是一定的,如果两个人编程,那么编程速度就会提高一倍,时间就会节省一半,为什么要编程.

硅谷流行结对编程:一人负责写代码另一人监控

- - TechWeb 今日焦点 RSS阅读
结对编程的坚定支持者Facebook程序员肯特--贝克(腾讯科技配图).   腾讯科技讯(马乔)北京时间8月28日消息,据国外媒体报道,英国著名女作家弗吉尼亚•伍尔芙(Virginia Woolf)认为,一位女作家应该拥有一个属于她自己的房间. 而在美国硅谷,部分科技公司则对程序员是否需要属于自己的独立工作空间表示质疑.

每日站会、代码审查、结对编程 之开源中国实践

- - 翟志军
在我来到开源中国之后,尝试将每日站会、代码审查、结对编程这三种编程实践带入团队. 而这个过程,我个人觉得是一项非常宝贵的体验. 先介绍下目前我们团队的结构:3名Java开发,1名前端,2名实习. 以下我不会详细介绍它们分别是什么,也无意讨论它们有什么好处坏处,本文侧重分享在实践它们的过程可能遇到的问题,以及我们是如何处理的.