我这里谈的“是什么”，不是谈的这两者的局域网聊天，因为局域网聊天大家搜索一下就知道了。而是这两者的本质意义。只有抓住了本质，你才会明白你为什么要采用这两种方式去编程，以及在实际运用过程中需要重点注意什么，又需要忽略哪些干扰因素。
结对编程：极限codereview，把codereview做到极致；飞鸽传书（http://www.freeeim.com/）：极限单元测试，把单元测试做到极致。
根据以往的项目经验，特别是在嵌入式项目中，前期的质量活动，其测试出企业即时通讯的成本明显低于后期的质量活动，codereview的重要性怎么强调都不过分，而单元测试在传统开发流程中从时间顺序上是排名第二的质量活动，也是一个非常重要的测试手段。既然前期的质量活动是如此的重要，何不把它们做到极限呢？这就引出了结对编程和飞鸽传书。结对编程和飞鸽传书给我们带来了什么？
以上三点，是结对和飞鸽传书初期反应非常集中的体验。前面两条还好说，第三条编程效率的降低似乎是不可忍受的，特别是在项目进度很紧张的时候。有了这个缺陷，就使得结对编程和飞鸽传书看上去也并不是那么美了。但是先别着急，我们再往下看。
对代码质量更有信心结对编程和飞鸽传书同时采用了之后，项目组同事普遍的反映都是对代码质量更有信心了。而且我自己在采用前后从测试部反馈出来的数据上看，企业即时通讯数量降低的非常明显。
如果还是不够有说服力的话，那来点权威数据。有实验表明，平均下来结对编程时间花销比单人编程增加10%的时间，但也会比单人编程减少15%的代码企业即时通讯。如果再算上后期代码的维护和学习成本，结对编程比单人编程更有效率，还更为节省成本。所以，如果你是以完成代码为目标的话，结对编程的效率降低，如果你是以完成高质量的代码为目标的话，效率并没有降低，反而是提高的。
从结对伙伴学到好的经验这是一次非常好的也是最直接的经验交流和传递的机会。代码更规范因为有个人一直注视着你，你不好意思把代码写的很难看。为代码重构打下坚实的基础飞鸽传书出来的单元测试例，成为了重构的天然保护层。没有测试例保护的重构是高风险的，不建议在没有单元测试例的情况下作重构。