4.5 结对编程中角色频繁互换是否会影响正常的程序编写的进行？

[GreyZeng]

原文地址

构建之法第三版中4.5.4中提到：

驾驶员和领航员不断轮换角色，不要连续工作超过一个小时，每工作一小时休息15分钟。领航员要控制时间。

那么频繁的轮换会不会影响正常的程序编写的进行呢？

[GreyZeng]

@GreyZeng 原文地址：https://www.cnblogs.com/cyy---336699/p/14953361.html

[GreyZeng]

在结对过程中，需要的是两人的共同商量、思考和设计，所以两个人都应该对程序、对设计有着充分的了解和认知，并且能够编写功能代码。驾驶员主要进行编码和单元测试，而领航员主要进行审阅文档，设计测试用例等相关事项，但这只是两个身份的在同一时间段的不同侧重而已，相辅相成共同完成，而非结对中一人仅负责编码和单元测试，一人仅负责审阅文档。而且对于结对中的某一人而言，长时间进行编码工作是一种极大的体力和脑力消耗，如果不进行及时的身份交换和休息，那么带来的将会是极低的编写效率和漏洞百出的代码，一种灾难。虽然时间段不一定是一个小时，但是即使的更换身份，不仅能进行精力的恢复，更能及时的重审自己的编码思路，保证和设计一致。

[GreyZeng]

  在没有进行结对作业之前，我认为角色互换是没有必要的，因为一旦熟悉了一个位置的工作，那么互换工作会造成不必要的麻烦，例如重新熟悉当前角色的任务，熟悉对方的代码等等。但是在实际进行过结对编程之后，我发现了角色互换的重要性。一是更好地全面地发现编程过程中的不足之处，如果从头到尾一直处于同一个角度，那么是很难发现问题的存在的；另外一点是可以缓解开发人员的压力，如果开发工作都是由一个人完成，那么压力无疑是巨大的，容易造成观察力和判断力的大幅度下降而造成不可避免的后果。事先设定好代码规范和代码注释等要求，就可以避免熟悉代码这个过程。
原文地址

[GreyZeng]

这不是一个硬性的时间规定，只是为了说明我们在结对编程的时候可以尝试互换角色，并且劳逸结合，至于时间看个人情况决定。本学期我们结对编程的时候，当一个人有了比较好的解决方案时，会去当驾驶员，另一个则转去当领航员，以此体验不同的角色，在两个人都比较累时，会闲聊一些轻松的话题，之后再接着进行。
原文地址

[GreyZeng]

我后来发现，结对编程与我预先设想的目的并不相同。我原本以为，结对编程是为了直接提高编程效率而诞生的，但经过一次实践之后发现并非如此。结对编程本质上是牺牲了两份时间，换取一份几乎没有bug的代码，从而间接提高软件开发的效率（因为后期复审变得容易了）。在这种情况下，由一个人长时间驾驶而另一个人长时间领航就势必会带来疲劳驾驶的问题，因此经常进行角色互换实际上是一个合理的选择。
原文地址

[GreyZeng]

经过亲身的结对编程体验后，我更加坚定我的观点，驾驶员和领航者的觉得并不需要如此高频的互换。由于队友对C#语言更为熟悉，所以很大部分编程工作的主题工作都由他完成，我负责小部分模块的编写以及软件的测试并向他提出一些优化的方向。在这个过程中我觉得效率会更高，因为如果每隔一小时交换一个人写，我会花费一些时间查询或询问一些语法而延缓进度，但是看着他写的时候边理解他的想法便可很大程度方便我进行后续的针对测试，提高了我们协作的效率。
————————————————
版权声明：本文为CSDN博主「Sharpzzz」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/Sharpzzz/article/details/125465655

[GreyZeng]

通过结对编程的实践，我发现结对编程确实可以减少 bug 的发生，但也确实如我想象中那样会降低工作效率。参考其他同学的博客，不少结对组都由于时间和地点的限制采用非结对编程的方式完成任务。

且针对结对编程代码质量更高这一问题。面对一些简单的 bug，如笔误等并不需要大量思维难度的问题，在独立编程时只要即时测试就可以发现。而面对一些复杂的 bug，如算法设计问题等，在结对沟通时也可能两个人都陷入同一个思维陷阱中，且相互确认反而可能盲目自信，在错误的道路上越走越远。因此结对编程的代码质量也不一定就远优于单人编程。

总的来说，在以后的工作学习中，我可能还是会更倾向于一个人编程而非结对。

原文地址

[GreyZeng]

本学期的结对编程，我认为题目非常失败，整个题目可以大致分为以下两个部分：

• 偏「软件工程」的要求，包括但不限于 Visual Studio 相关功能的使用、GUI 编写、动态链接、暴露接口、前后端解耦对接、令人迷惑不已的题目描述等。

• 偏「程序」的要求，具体来说，一个字符串处理 + 一个 DAG 最长路 + 一个 NP 问题。

整个过程中偏「软件工程」的要求占据了绝大部分，然而这部分很难进行结对编程，因为大部分时间都是在试错和搜索，强行结对只能变成两个人一起试错和搜索，远不如分工后各自完成的效率高。

结对编程的意义是在编写复杂代码时可以做到实时代码复审，就地解决尽可能多的 bug。因此只有当偏「程序」的要求占据主要部分，拥有一定的复杂度后，结对编程才变得有意义。换句话说，对于简单而且很快能写好的代码，为什么要两个人一起写呢？本学期结对编程的作业显然不符合这个要求。

综上所述，我认为本学期结对编程的作业可以让我们很好地在实践中了解实践工程，但却不是一个适合结对编程的项目。

最后回到问题本身，我还是持有原来的观点，那就是两人角色没有必要互换。此外我还有一个新的问题，那就是工程中需要编写「足够复杂」的程序的项目是否占据主流？这个「足够复杂」的含义是采取结对编程可以最大化经济效益。

原文地址

[GreyZeng]

假如结对编程的两人只是一个人沉默地写代码，一个人沉默地观察着，持续一段时间后换班的话，我认为势必是会影响程序编写的过程的，且效率低下。每个人的编程风格都不一样，当我们拿到别人的代码时，肯定不会觉得像阅读自己写的代码一样通顺和自然。因此我认为结对编程时，双方应该随时交流各自编程的思路，如果出现了疑问一定要马上提出，以免交换后对着对方的代码一脸茫然，再浪费大量的时间去询问代码的含义和目的。顺利的情况下，我认为有默契的结对编程同伴可以达到“合二为一”的境界，即两个人对对方的思路和习惯烂熟于心，结对时已经养成了属于两人自己的习惯和风格，仿佛就像是一个人在同时思考和编写一样。这也是我所憧憬的伙伴关系。
原文地址：https://bbs.csdn.net/topics/613441716

[GreyZeng]

在结对编程中，交替性地担任担任者和审阅者是有助于提升编程效率的。对于传统的单人开发模式来说，在完成自己的任务后，可能还需要成倍的时间去与小伙伴交接以完成组队任务，尤其是在API的设计、测试等部分，并不是凭一己之力能够完成的。而结对编程就很好的改善了这一点，开发者始终处于开发或审阅工作中，可以全方位地了解到开发进度和接口的设计，有效避免开发完成后漫长的对接调试时间。所以，虽然结对“轮换”制虽然并不能让领航员得到充分的休息，但是当赛车（开发过程）到达终点后，驾驶员和领航员都可以快速对车辆（程序）进行维护。
————————————————
版权声明：本文为CSDN博主「Wit#23」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_46473364/article/details/131266284