构建之法阅读笔记02

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

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

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

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

一、领航员误区

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

1. 发号施令者

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

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

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

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

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

2. 拼写纠错者

结对编程中不好的习惯:

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

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

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

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

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

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

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

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

3. 吹毛求疵者

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

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

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

4. 默不作声者

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

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

5. 心不在焉者

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

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

澳门新葡亰 1

网站地图xml地图