我们看到封面，你可能会觉得，当我们遇到问题的时候，请教前辈或者是讨论解决方案的样子，又或者是 带新人时的样子，想像起来确实是这样。
但，什么是 Pair Programming，就是结队开发，一种敏捷开发模式，2个人一组，1台电脑，共同开发同一个功能，不是分工合作，是一起合作，一个人负责执行，一个人负责动脑提供想法或是找出问题。
最大的目的就是精实开发，提升专注力，并且同时 Code Review，一个功能有两个人会(提升知识传播效率)，可以避免一个功能只有某一个组员会，请假或离职之类的接手问题。
在网路上的中文资讯很少，可能是因为他的缺点，每一件事都需要两个人力成本，并且团队成员的能力要求需要匹配 (比如说 两个都很弱，或者两个都很强)。
以上就是 Pair Programming 概念
實際執行上的限制
接下来就是我个人的感受理解
- 人员匹配问题
- 弱 by 弱：大家一起卡着问题，最后导致进度Delay，又或者一起妥协潜在问题，遇到再说。
- 强 by 强：强者的大脑应该通常像是电脑CPU RAM一样在进行处理跟运算，如果要稍放速度，带着另外一个人进行开发，那效率就会变得很差，因为高集中度1小时 跟 2小时 还是会有差异。
- 强 vs 弱：这就像是前面提到再带新人的方式一样，但 Pair 不是为了带新人。
- 人力成本与时程压力：这部分就会变成明明很多人，但是进度却没有很快的假象，因为目标是 用人力成本换未来的维护成本 ，但两个人的时程压力一定会来得比一个人还要大，然后就会有 代码品质 跟 人力成本 的冲突。
- Pair 开发项目需要拉小：例如像是需要初创 底层开发，在两个人的思路上应该会很卡。 团队开发Style 需要规范：如果没有规范，那有可能最后就是两个一起妥协，可动就好，越硬改 就越改不动。
- 成员对团队专案是可动就好，还是怎样更好，很影响到未来的维护性
总结
总的来说，敏捷开发 需要适情境使用，例如在一个短期需要冲刺的项目中，并且大家都有共同目标达成，就很适合，但如果用在日常中，实际上并没有明确完成目标 (有需求就做，不是完成所有项目就是任务完成的)，就不适合。
Pair 我认为也一样，当遇到棘手的问题时，找一个熟悉相关问题的伙伴，Pair 就能够发挥最大作用，但如果在日常中(例如 前端切版)，Pair 感觉不会有太大的意义。
如果Pair开发遇到问题的时候，是 Pair妥协，那不如自己开发自己妥协
如果想要程式码品质，我觉得应该要确实地做到 测试程式码 (TDD, E2E TEST, Unit Test, 提高测试覆盖率)，精实的 Code Review。
而不是依赖 Pair。
(不负责任评论，如果有其他想法或纠正，欢迎交流)
