关于结对编程的一些问题

前言

  最近由于公司项目,有机会尝试结对编程(pair programming),实践了3个月,也有了自己的一些心得体会,本文以Martin.Fowler的《结对编程模糊概念》来展开叙述。

1. 实践敏捷过程一定要“结对”吗?

This is utterly false. 'Agile' is a very broad term defined only in terms of values and principles, most notably in the Manifesto for Agile Software Development.

  正如Martin所言,敏捷宣言并未提及结对编程是必须的,敏捷只是一种思想,结对编程仅仅是实践中的一个非必须的组成部分。即使XP被强烈推崇,也不代表结对编程适用于任何公司或者项目。

  就个人体会而言,目前项目组内会有Switch pair的过程,我的理解是pair的过程更多的注重团队成员间的知识分享以及相互之间的沟通、检查代码等,带来代码质量上以及、知识流动上的优势,要因项目或成员而异。

2. 极限编程迫使你结对吗?

I would say that pair-programming is usual for XP teams. I wouldn't say that a team that doesn't do pair-programming thus cannot call itself an XP team. I should also point out that to most XPers I know the question of whether a team is XP or not is uninteresting; the real issue is whether a team is effective.

   Martin所赞成的是团队开发效率或者说结对编程是否适合团队。

3. 如果我不喜欢结对编程,我就没必要去实践它?

  Make sure you have someone who really knows how coach you, so you can be sure you're evaluating the real thing.

  针对这一点,我觉得我还是有切身体会的,真的很同意Martin的观点。如果你经历过一个不好的pair体验,你就要回忆并且追问下,是否你找到了“合适”的parter来一起pair,而不是那种话不投机半句多、我写你看着,这种同伴。

  往往pair的过程中两个人的水平会有所差距,这个问题要从下面几个角度考虑:

  1. 如果你是low的一方,你需要一个什么样的同伴,你希望同伴是如何回答你的各种疑问,如何正确提出问题,怎么样提问能让对方乐意回答你的问题,如何让pair的对象不觉得你很low,如何找一个有耐心的同伴交流,而不是讽刺挖苦?

  我觉得这个问题是一个很难平衡的问题,可能在大多数的情况下,要虚心请教、加速学习,努力跟上设计思路,并且提出自己的观点,让对方觉得你不是一个“无用之人”,诚然,最开始总是最难熬的,“命运”是公平的,如果有一个更Nice的同伴,可能你的学习努力程度就会稍若些;如果你的同伴很自傲,说话略带讽刺,这可能会激励你更快的学习。尽可能找一个适合自己的parter才是开始pair的关键。

  2. 如果你是High的一方,你是否思考过,low的一方的感受,你应该如何帮助low的一方提高能力水平,如何能在你累的时候,low能替你完成你的思路?

  俗话说的好,授人以鱼,不如受人以之渔。可能做为能力稍强的一方如何引导同伴去融入代码,融入设计思维,而不是我自己也行,不需要知识分享也能完成,或者你水平太low,问题太多,我不需要你这样的累赘。其实pair的一方面是分享知识的过程,如果简单简单理解为完成项目任务,则会错失很多提升自己的机会,如果是这样你要考虑你是否适合pair。

  3. 两个人水平相当,有时,大家思路一致,互相抢键盘来完成代码,而有时,甚至两个人为了一个命名争的面红耳赤?

  这是一个相当普遍的情景,而往往后者出现的次数更多。这里有一些对代码理解上的冲突,有一些实践上的规范,还有一些人内心的虚荣(不接受别人对自己的否定,即使是错误的也要坚持),这时首先要思考下自己坚持的东西是否是正确的,自己是否能承认不足(不完美),其次可以找“第三方”来决断矛盾。从实践的角度出发,如果事事都要第三方决断的话,极有可能你们两个之间的pair关系早以不存在,我觉得处理pair矛盾的过程是两个人互相理解、互相包容的过程,一味最求自我,这样只能单打独斗。

  当然,如果两个人,“化学”作用比较好的话,会非常happy :)

4. 结对编程对降低工作效率?

that would be true if the hardest part of programming was typing

  一些结对编程的支持者认为,结对编程的效率会更高,他们(她们)可以持续讨论、互相review代码,这样可以保证高质量的代码。而更多时候“工作效率”是无法衡量的,特别是在解决很困难的问题时,一个人可能会陷于某种“极明显”的错误中,而不得要领,这个时候如果两个能保持独立思考的人往往效率更高。

  在我的pair中,有时我的任务是当代码开发遇到困难时梳理代码的作用,从新overview代码思路,解决困难,一个人的能力是有限的,而两个互补的人会产生1+1>2的效果。

5. 结对编程只适用于解决困难代码场合?

Except this: writing boring rote code is a smell. If I'm writing boring repetitive code it's usually a sign that I've missed an important abstraction, one that will drastically reduce the amount of rote code to write. Pairing will help you find that abstraction.

  简单并不代表没有重构机会或者说没有机会写出更完美的代码。

  在我的pair过程中,partner总是在提醒我要重构,抽取代码段,也许这就是一种外在的推力,来开发更优质的代码。结对编程是提成代码能力的过程,你如何知道你写的代码是最最优美的呢?看看codewars上大牛们代码,你自己都会觉得汗颜。

 

posted @ 2015-07-14 21:18  史蒂芬King  阅读(935)  评论(1编辑  收藏  举报