美高梅官方网站66159

在结对编程的task中,结对编程需要学习

作者:美高梅官方网站66159    来源:未知    发布时间:2020-05-01 10:02    浏览量:

在过去的几年里,我有过许多结对编程的经历。有时在我的团队里进行,有时在客户那里,有时在coding dojo(一种编程模式,几个程序员一起合作完成一个任务),有时在我的开源项目里。对于那些知道如何结对编程的程序员来说,这种模式很棒,很高效。
但是你不能指望在两个程序员面前摆台电脑,就指望他们一开始就做得很棒。结对编程需要学习,程序员需要知道实施者(敲键盘的人)和领航员之间的区别。下面来看看些细节。

按照敏捷开发的要求,我们测试小组开始了第二个story。我领到了结对编程和跟着江霄一起完成关于.Net下对具体的项目代码写出测试Demo的task。

在结对编程的task中,主要又分为了概念性认识和具体推行两个子任务。这次主要还是单元测试理论性的一些基本认识吧。

重点:两人合作中与人交流

在结对编程中,我遇到了一些误区,列在下面。

定义:

结对编程就是两位程序员坐在同一工作台前开发软件。也就是说,两位程序员来完同一个设计,一个作为领航者在后边说代码怎么写,另一个作为实施者写代码。

我们在工作中需要对同伴的工作进行反馈,表达感谢,阐明要求,指出不足,等等。怎么讲,才可以让对方能听得进去?

一、领航员误区

优势:

对项目:

(1)两个程序员具有相同的缺点和盲点的可能性很小,所以当我们采用结对编程的时候会获得一个强大的解决 方案。人多力量大,人多点子多。(可能会出现过度讨论,浪费时间;当然,也可能创新出更好的方案)

(2)如果程序员的经验积累足够,是很容易看出存在潜在问题的代码的,即表面上实现了功能,但实际上是一种糟糕的做法。

(3)两个有经验的程序员同时在一起工作,看起来好像浪费了一个人的时间:但实际上的效果确实完成了更高质量的代码,程序不那么容易出BUG。

(4)一定时期内打乱配对。好处:促进交流,融洽关系;每个人更熟悉具体模块和整体项目;不再为人员流失而过度困扰;不再维护繁杂文档。

对程序员:

(5)它可以促进参与项目的程序员自身水平的提高,一对程序员工作的时候,水平较低的一方会潜移默化地受水平略高的程序员影响,学到一些新的东西。而水平高的一方同样因为不断地把自己的想法说出来而整理了自己的思路。

(6)提高效率,尤其是遇到困难时,两个人回去积极解决,而不是有时候的走神、跑偏、私人聊天等。真心是压榨呀~

(7)更少的受到打断。人们更不愿意打断两个结对编程的人,而单独工作的人却容易被打断。

反馈就是告诉对方你对他的评价,人就像洋葱一样,有很多层次,

1. 发号施令者

劣势:

可能出现的问题:(1)、过度讨论,浪费时间;(2)、水平高低不齐,效率低下;(3)、想法过多,思路“跑偏”;(4)、领航者:过度关注细节;一意孤行,默不作声,心不在焉等;(5)、实施者:深藏不露;目中无人;不知所措;思维跳跃;工具不熟悉等。

1.最外层:行为和后果 2.中间层:习惯和动机 3.最内层:本质和固有属性。

喜欢发号施令的人总是对敲键盘的人说:“到末行,加个反括号,然后…”。他不去关注解决方法和下一步该怎么做,而过度关注一些编程细节。

要求:

水平差的不太远的程序员和自己配成一对;只用一台计算机;大家选一个人坐在键盘前面负责输入,另一个人坐在后面口述(会不会造成一个人不思考了?不会,因为一个人停顿的时候另一个人会主动的去继续思考;会不会一个人思路太快,另一个跟不上?不会,因为第一个人听不懂他就写不下去,会问)。

两个人要不断的交流,频率不应低于一分钟一次。整个的设计思想由后面只动口不动手的人主导,而由操键盘的人做实现。由于人的思维速度是快于输入代码的速度的。那么观看的人可以有空闲的时间做额外的思考,观察代码写的有没有问题,结构有没有问题。

可以两个人分时交替角色。

虽然编码通常比一个程序员单独工作更快地完成,但是总的程序时间(程序员数目×花费的时间)增加了。管理者需要在工作更快的完成以及缩减测试和调试时间和更高的编码成本之间平衡。对于那些程序员没有完全理解的任务上,程序员期待更多的创造性,挑战,以及高复杂度,此时使用结对编程最有帮助。在简单的,程序员都完全了解的任务上,结对编程导致生产力的净下降。

根据果冻和荔荔的范例,了解到当反馈是关于行为和后果时,行为可以改正,成果可以弥补,对方还是有挽回局面的机会,当反馈上升到攻击对方的习惯和动机,被攻击的一方就比较难表白并且澄清动机;当攻击深入到核心,被攻击一方已经无法回应,因为攻击的目标是自己的固有属性,无法改变的,涉及到人的本质,也很难改变。

事实上,他希望他自己来掌控键盘。所以当你碰到一个喜欢发号施令的人,那么将键盘交给他吧,转换领航员的角色。

发展:

远程结对编程,就是共享桌面,拓展硬件、解决地域限制;但不利于协作,比如有延时键盘控制混乱等、乒乓结对编程,就是观察者和驾驶者(操作者)测试用例的编写和修改(了解即可)。

总结:对于结对编程还需要进一步的认识和探究,这里只是粗略的介绍。尤其是在项目中怎么推行和解决推行过程中的问题,才是这个课题的重中之重。

如何给别人提供容易接受的反馈,有一个“三明治”方法,最好先来一片面包,做好铺垫:强调双方共同点,从团队共同的愿景讲起,让双方处于一个安全的环境,然后再把肉放上,这时就可以把建设性的意见加工好,加上生菜,佐料等。怎么准备这块肉也有讲究,在提供反馈时,不宜完全沉溺于过去的陈年谷子烂芝麻,给别人做评价,下结论,不妨换个角度,展望将来的结果,强调【过去你做得不够,但是我们以后可以做得更好】,在技术团队里,我们的反馈还是要着重于行动与后果这一层次,不要贸然深入到【习惯和动机】、【本质】,除非需要触动别人内心深处,让别人悬崖勒马,然后再来一片面包,首尾呼应,鼓励对方把工作做好。

2. 拼写纠错者

结对编程中不好的习惯:

拼写纠错者坐在你旁边,纠正你输入的每个错误字符。当然,他没有时间来真正的进行导航。

不拘小节的人 两人在一起近距离地工作,但是不注意个人卫生和互相尊重;

style="font-size: 16px">喜欢发号施令的人,不去关注解决方法和下一步怎么做,而关注编程细节;

style="font-size: 16px">拼写纠错者:纠正你输入的错误字符,没有时间真正来导航;

深藏不露者 仅仅在敲代码而不告诉别人他在做什么。 style="font-size: 16px">领航员不得不靠自己去弄懂代码。关于用什么方法,选择哪种设计,领航员和实施者之间完全没有交流;

style="font-size: 16px">跳跃很大的人:他们喜欢在代码中进行大范围的跳跃,这样领航员就不知道进行到哪里了。

和纠错者商量一下,当他给你纠错的时候让他请你喝一杯咖啡(或者任何你想要的东西)。

在过去与他人合作时,不知道如何提意见,在过程中会产生摩擦,太鲁莽,会使两人合作产生障碍,经过学习,知道了不好的习惯,以书为鉴,避免不好的习惯,给他人反馈时,使用“三明治”法,更宜接受。

3. 吹毛求疵者

吹毛求疵者会指责你写的每行代码。当他的意见正确时,他会一意孤行,不用你已经写好的代码,而完全照着他的想法。

就如自由爵士音乐人都是复用其他乐队成员的音符,来构造成一首曲子一样,好的结对编程也应基于现有的基础上进行推进。

试着转换角色,也许吹毛求疵者就会变成一个目中无人的人。

4. 默不作声者

默不作声者是那些几乎不发表意见的人。他仅仅坐在那里看着你工作。

试着问下他对你的方法有什么意见,或者问他下一步该写什么测试代码。

5. 心不在焉者

心不在焉的人企图让你分心,而不是提供给你有建设性的意见,帮你解决问题。

那么让他离开吧,比起一个让自己分心的人而言,不如一个人编程。

图片 1

二、实施者误区

1. 深藏不露者

深藏不露者仅仅自己敲着代码而不告诉别人他在做什么。领航员不得不靠自己去弄懂代码。关于该用什么方法,该选择哪种设计,领航员和实施者之间完全没有交流。

领航员需要问问深藏不露者关于他的计划或想法。

2. 目中无人的人

目中无人的人通常忽略领航员的所有建议,大多数是因为他们觉得自己的想法或编程技能更胜一筹。

当碰到一个目中无人的人时,立即停止结对编程吧,开始下一个任务吧。自大的人往往也不会是个好的领航员。他们很可能变成发号施令者或是吹毛求疵者。

3. 不知所措的人

不知所措的的人往往不习惯结对编程,非常紧张,不能掌控全局。

确保自己的领航员角色做到最好。小心的提出意见,对于不知所措的人主要给予鼓励。

但是,大多数程序员开始都是这种情况。所以,不要对他们的结对编程期望太高。让他们首先成为一个领航员,或者让能够很好的处理人际交往问题的领航员在他们旁边。

4. 跳跃性很大的人

跳跃很大的人喜欢在代码中进行大范围的跳跃,这样领航员不知道进行到哪里了。

领航员需要让他慢下来,问他关于他的计划,并确保自己比他知道更多的快捷键。

5. 不熟悉工具的人

不熟悉工具的人不知道开发环境的快捷键,效率非常低。

交换角色吧,让他看看你的技巧。或者打印一张印有快捷键的cheat sheet。

我相信还有其他的误区,如果你有什么想法请写在评论留言吧。

原文: planetgeek.ch  编译:伯乐在线

下一篇:没有了

更多新闻推荐

Copyright © 2015-2019 http://www.77zhth.net. 美高梅官方网站66159有限公司 版权所有