结对编程的总结

结对编程的一些总结

Jessy&Terry

结对早在Julian提出之前我们就在实行，只是一直没有出现一个概念给他冠名。

先来看一下从网上扒来的结对定义。我从结对的表现形式和结对的组合方法上对他们进行了一句话的概括。

形式上：one computer,one screen,one mouse，one keyboard and two chairs

      组合方法上：不断地打乱配对

我们的不认同点

我们所在实行的 同时我个人认为比较适合我们的结对不同于上述意义上的结对。主要的不认同点在于上述归纳的两个概括点。

结对形式

上述意义的结对就行为描述上来讲是这样的：某人坐在键盘前实现代码。另某人坐在其身后，在敲代码那位遇到难题时一起出谋划策。在没有困难时调戏前面那位曰：“看别人敲代码真是一种享受。”

个人认为这种形式上的结对不适合于我们的开发。结对的两个最明显的弱项一是双份时间二是引起掐架的问题都被这种行为很好的体现了。首先谈一下最明显的双份时间问题：解决时间浪费的组合应该是结对双方水平差距较大。所浪费掉的时间可以被认为是培养了新人。但是我认为这种组合本身就存在问题，也许它只适合于培训而不是周期紧张的开发。然后看一下掐架的问题：在水平相当的情况下，这种方式在引起掐架方面就显得很有优势了。做一个自认为比较生动的比喻。某人和另某人要从喜马拉雅山脚下去山另外一边。在两个人都没有能力爬或者飞过去的前提下，只能绕过去。这样问题就来了。两点确定一条直线，但能划出无数的弧。某人会提议从印度绕过去，而另某人却觉得印度正在喜马拉雅那建滑雪场，我们还是从尼泊尔绕吧。但是藏独那伙儿全窝在尼泊尔，所以某人还是坚持走印度。你看，太容易了。

组合方法

首先得承认我对上述结对的组合方法的排斥有着自己的私念，就是当我和伙伴经过长时间的磨合已经能够形成某种默契时，我实在是不愿意再去和另外一个人归零开始。伙伴终归不是酒吧里的舞伴，全新的总是不好。

虽然有一个没法反驳的理由是在团队间更换结对对象有利于提升整个团队的综合能力，但我还是绞尽脑汁想了一个在提升这个综合能力的过程中可能会有的一个问题也许能导致整个计划适得其反：如果两个人确实没有办法磨合呢？或者说是如果另某人和另另某人的磨合必须损失掉其中一个的积极性呢？在决定去做以前，我总是习惯用这些极端情况吓唬一下自己。虽然不一定存在。

 

我们正在使用的方法

还是从结对形式和组合方法两个方面来说。

结对形式

上述的结对形式对任务进行了一个很模糊的横向划分——两人同时做同一个任务，以至于写同一个方法。我们的不同之处在于首先对任务做了一个纵向的切割。即一起确定一个框架流程级别的实现思路，想好切割点，约好接头暗号，ok，开始吧。实现过程中遇到问题？然后再拿起结对上one，one，one，one and two 的方法。针对这个困难来做一个横向的攻克。

所以说，我们的结对不同于正常概念的地方在于，我们不是一直在做横向攻克，我们首先做的是纵向切割，然后在有必要的时候实行横向攻克。

组合方法

组合方法就不是我们能讲明白的事情了。因为我们也没有尝试过。只是恰好组合在一起，恰好配合很默契，恰好提出意见说概念上的组合方法在沿用的时候有风险罢了。个人来讲我只是不喜欢经常性、随机性的更换。

 

综上所述，我们把这种结对定义为，有着jessy和Terry特色的结对编程道路

 

结对过程中应该注意的事项

1.    初次结对不要选择太紧的任务

2.    对于不同习惯的伙伴，要互相理解。不要自我中心

3.不要为了坚持己见而坚持己见，最好先按照别人的思路走一遍别人的方法。

4.要求伙伴和自己一起攻克难题之前，先确定一下伙伴是否正在进行一个不能打断的思路。

5.任务交付，出现bug。

      在那句惯性的“这一块不是我写的”说出来之前，不管是不是真的如此，最好先考虑一下