说到结对，不仅有编程结对，其实在XP中，这个概念可以更宽泛一些，还可以是设计结对、评审结对、单元测试结对。
设计结对
设计结对是在对某个模块开始编码之前，两人共同完成该模块的设计，这种设计通常不会花费很长时间，不会产生设计文档，更多的是讨论交流，主要考虑是否符合总体架构，是否足够灵活，易于重构等。
单元测试结对
单元测试结对通常是说一个人编写测试代码，另外一个人编写代码来满足测试。这样，任何一个人对设计理解有误，代码都无法通过单元测试，从而避免由同一个人编写单元测试代码和程序代码带来的黑洞，往往可以发现更多的问题或缺陷。
评审结对
评审结对是在编码活动完成、通过单元测试后进行的。一般采用一个人讲述代码组织和编程思路，一个人倾听、提问的形式。这种评审模式更多地强调了相互交流，这会比一个人单独评审，独立撰写总结评审意见的模式效率要高得多，文档、邮件也减少了。
其实，如果两人编程结对了，编程的过程其实也就是复审的过程，完全可以省略评审。
设计结对、评审结对、单元测试结对这三种方式是对结对编程实践的有效补充，操作简单，收益却很大。
-
编程结对，在任一时刻都只是一个程序员在编程，效率到底有多高呢？ 1+1>1是肯定了，但是否1+1>2呢？
结对编程不能始终保证开发质量和效率始终高于单人编程。
只有两个经验相等的人结对才有可能真正提高编码效率。
结对编程始终是两个人的合作行为，其效果会受到多种因素影响。譬如，两个人的性格、个人关系、沟通能力、技术是否互补等都会影响最终的结果。
至少两个极端情形下，结对毫无益处：
第一， 需要静心思考的问题。这时完全可以分头行动，等各自有了理解或解决方案再来讨论；
第二，琐碎毫无技术含量的工作，不得不手工完成的。这种工作考验的只是耐心，不妨分头行动，效率肯定比结对要高。
结对编程的要点
- 结对编程是一种质量保证的方式
- 就像Scrum一样，并不是所有的团队都有能力实行XP，也不是所有的团队都适合实行XP，视实际情况而定。
https://support.huaweicloud.com/reference-devcloud/devcloud_reference_0017.html#section5
