让我们一起探索分析结对编程成功的特征原因。
结对编程正在逐渐成为主流的编程方式。有着两年结对编程经验的我注意到,结对编程真的很棒,甚至可谓是神奇。但有时候,却又阻碍了我们的开发进程。我想探究这背后的原因,并搞清楚如何才能让结对编程一直发挥正能量的模式和方法。
我的结对经验
我认为先说明我自己的结对编程经验,有助于各位更好地评估以下的相关内容。我已经结对编程将近两年时间,就职过2家不同的公司。一家是咨询公司,我们开发了客户端应用程序。另一家是创业企业,开发了一个大型的SaaS产品。在这段时间,超过20个有着不同背景、性格、技能、经验和文化的开发人员和我结对编程。
边注:结对编程还有一个好处就是能让我与很多厉害的人共事,成为朋友。
有效结对的特征
回想我以往的结对经验,很多好的坏的体验似乎一下子历历在目,恍如昨天。我将此总结成为2*2的矩阵。
结对编程矩阵
定义
效率代沟
从我的观察角度来看,两个个体结对时相关性最强最具区别化的因素就是两者之间的效率。这些因素包括——他们以往各自的经验、领域知识、语言知识,等等。效率的另一种表达方式就是他们各自的输出潜力,包括速度和质量。为了讨论的方便,在这篇文章中会把高效和低效的程序员分别形容为“高级开发人员”和“低级开发人员”。
利好
两个人结对编程比各自独立工作的期望优势。
效率差距小的结对编程
根据我的经验,效率差距小的结对编程普遍比差距大的要更好。原因或许是因为开发人员拥有的共性更多,交互时也更自在。在矩阵中列出的要点已经非常清楚。从本质上讲,差距小就意味着他们更能理解和相互尊重,愿意经常沟通,共同学习进步。这将是一场愉快又双赢的互动。
弱弱结对
我的观察结果告诉我,弱弱结对比强强结对的利好更多。为什么呢?大概是因为低级开发人员意见性不强,没有那么自负,更注重学习,而不是坚持自己是“正确”的。
你知道“新同学交友”效应吗。假设你还是一个孩子,在某个学年中途随你的家人搬迁到一个陌生的小镇上。这时候如果班上另外一个孩子大约也是在相同时间转学过来的,那么你们更容易成为朋友,因为你们的处境相同。结对编程也是如此。如果你们对某个新的应用/技术/语言/等等都不熟悉,那么之后的研究探索,由于处在平等的位置,你们不但更谈得来,而且合作解决问题的时候更契合。
两个低级开发人员结对的首要目标应该是学习。
强强结对
如果是两个高级开发人员结对编程,搭档起来会很难。因为每个程序员都是不同的,想法和意见也不尽相同。经验越丰富,越倾向于坚持自己的观点,并且还会越自大。而当其中一个人过于自大时,另一个人就只能当“应声虫”了。
更糟糕的是,如果两个人都很自大。此时他们会不断地争执争辩以在驳倒对方,于是两人之间的关系会紧张,充满敌意。我见过更糟糕的是,两个人甚至从头到尾一句话都不说,这显然是负面效应了。
良好的强强结对应该是相互尊重的。相互交流,辩论,讨论,还有规划,一起创造专业化的水平。强强联合导致的是雄厚的生产能力。
所以,两个高级开发人员结对的首要目标应该是产量。
强弱结对
这种结对安排往往发生在有新的开发人员加入公司,或切换到新的开发环境的时候。为新来的人员搭档一个高级开发人员,能让前者快速融入到团队中。但是如果选择的这个高级开发人员不合适,那么就有可能损害低级开发人员的信心和士气。
期望
首先领导人员必须明白人员安排的目的是尽可能快地推动开发进程。任何有着利害关系的人员也应该明白这个道理,这些人员包括其他开发人员、设计人员、QA等,尤其是高级开发人员。并且我们不应该给这个老带新的组合很多压力。
输出速度会变慢,因为生产的同时发生了指导。
指导
高级开发人员应该明白他们的角色是指导低级开发人员,而不是迅猛生产。
好的导师,愿意聆听和回答问题,观察并提出引导性的问题。
但是人的本性让我们很难做到如此。下面是一些要点:
不要告诉他们要打什么,要做什么,也不要直接就演示给他们看。不可否认这样会省事很多。但是你应该让他们看到自己所犯错误的后果,让他们自己去思考为什么这样不对,让他们自己纠正错误。允许他们问问题,然后用引导性的问题回答他们,让他们自己去探索。如果他们陷入了死胡同,就伸手拉一把。
我记得有一次我和一个完完全全的新手同事结对完成任务。因为那时压力真的很大,我选择了毫不留情地拖着他往前冲。虽然也经常道歉,但明显他的心情一直很糟糕。
好的导师应该具备充足的耐心和自信,积极促进低级开发人员的成长,而不是让他们成为人云亦云的应声虫。但是在这个领域,这样的导师实在是太少了。每个人都忙着完成自己的事情,又或者根本就没有教导他人的技能。下面这些问题或许有助于我们确定某人是否是一个好导师:
是否愿意与低级开发人员分享知识,帮助他们?是否嫉妒低级开发人员的技能,或是反感他们提出意见和见解?是否愿意牺牲自己的舒适力争团队的利好?
高级和低级开发人员结对的首要目标应该是指导和学习。
结论
正如我上面分析的那样,每种结对情况都是不一样的,关键是要承认他们的不同,了解如何使其能够更大地利好于团队。
祝编程快乐!
原创文章,作者:ItWorker,如若转载,请注明出处:https://blog.ytso.com/tech/linux/47352.html