问题标签 [pair-programming]

• 您是否参与代码同行评审或练习结对编程，或两者兼而有之？
• 您是否能够证明使用这些实践提高了软件质量？
• 您在实践过程中观察到了哪些好处和坏处？
• 您在实施过程中遇到了哪些障碍？

在我自己的案例中，我们的开发团队对许多不同的软件工件（需求分析、测试计划、代码等）进行了同行评审。对等编程甚至不被视为一种选择。

同行评审实践是自上而下的，开发人员从未接受过它。我们有一个外部 SQA 小组从活动中收集指标，但这些数字毫无价值，因为这项工作是半心半意的。经过多年的“官方”做事方式，开发人员已经开始集体无视规定的程序。

现在，对于错误何时插入生命周期的可见性降低了。不进行同行评审导致团队专业化程度提高……没有人真正了解系统专业领域之外的组件的需求/逻辑。

了解您在同行评审或结对编程方面的经验，尤其是成功案例，将是很有价值的。

我的一个朋友正在解释他们如何在他的工作场所使用 TDD 进行乒乓配对，他说他们采用“对抗性”方法。也就是说，当测试编写人员将键盘交给实施者时，实施者会尝试做最简单（有时是错误的事情）以使测试通过。

例如，如果他们正在测试 GetName() 方法并且测试检查“Sally”，则 GetName 方法的实现将是：

当然，这会（天真地）通过测试。

他解释说，这有助于消除检查特定固定值的幼稚测试，而不是测试组件的实际行为或预期状态。它还有助于推动创建更多测试并最终实现更好的设计和更少的错误。

听起来不错，但在与他的短暂对话中，通过一轮测试似乎比其他方式花费了更长的时间，我并不觉得获得了很多额外的价值。

您是否使用这种方法，如果是，您是否看到它得到了回报？

团队中的一些成员在一起编程时遇到了问题。不同的性别，不同的文化，不同的年龄。如何处理这些问题？- 不要将它们配对在一起，或者 - 将它们配对在一起，让它们达到“黄金中间”

我正在寻找一个好的、免费的（首选）屏幕共享程序，它适用于 Windows（Vista x64、Server 2008）的结对编程和代码审查会话。它应该允许任何一个人控制屏幕，并通过体面的宽带连接对文本编辑做出相当大的响应。其他功能，例如绘制/标记/注释其他人屏幕的能力会很好。

编辑：这将被远程位置的开发人员使用。

阅读XP 书，我心中有一个我无法解决的矛盾，想知道你们是否可以提供帮助。

XP 说在索引卡上写故事，分配给开发人员，让她估计任务需要多长时间，然后使用结对编程来完成编码。

因此，她和她配对的开发人员必须选择执行他或她的任务。根据该选择，他们执行的工作将计入她为该任务所做的估计。这个估计是否仍然有效，因为它似乎取决于她与谁一起工作？

我在一个极限编程团队工作，每天结对编程。最近，我越来越经常做一些反馈缓慢的事情，大约 3 分钟。例如：改变一些东西，重新编译，运行，看看性能是否有所提高。我认为它削弱了结对编程的质量，而且我认为它对结对编程的影响比对单独程序员的影响更大。如果我一个人，我可以做其他事情，但是如果我是结对编程呢？你会怎么处理？

我认为一般来说，同行评审是开发过程中非常好的一部分，他们经常会发现或质疑最初编写代码时不明显的事情，并使您更加自觉，因此您可以更好地格式化，发表评论等。

然而，如果你是结对编程，你实际上有一个实时的同行评审，那么作为流程的一部分，还值得有一个同行评审吗？您可以进行配对同行评审吗？

我问，结对编程开始在我工作的地方发生，通常这被视为同行评审的替代品。我不太确定，但认为开发人员花在结对编程和同行评审上的时间可能会损害生产力。

前段时间有一个类似的问题，但重点不同，没有明确的共识

我们公司一直在考虑取消我们的面试程序，让每个候选人与一些程序员坐下来 4-5 小时，然后做一些结对编程。

我在理论上喜欢这个想法，但我不确定如何才能真正让每个候选人都公平。你如何评价他们？他们的输入真的不取决于每个程序员那天的工作吗？

关于这是一个好主意/坏主意或如何使其发挥作用的任何想法都是我在这里寻找的。

干杯!

编辑：

结果 - 按要求

我们将像以前一样进行面试的第一步。电话后是面对面。我们不会让他们回来进行第三次也是最后一次烧烤，而是让 3 名开发人员回来与团队的所有 7 名成员坐在一起。我们决定让团队决定随后雇用谁。

我们得出这个结论有几个原因。我们相信这将赋予开发人员权力，让他们可以选择他们的工作对象。第二个原因是群体动态。我们认为拥有良好的团队动态非常重要，而且在您雇用一个人之前很难判断他们是否适合。

所以最终的结果是我们将继续进行结对编程课程，但以完全不同的方式和完全不同于最初预期的方式。

任何对这种方法的想法或批评都非常受欢迎！！（此编辑在下面发布为答案，因此如果您认为这不是最佳方法，请随时投反对票）

敏捷中的结对编程要求我们将支付给单个程序员的薪水增加一倍。当然，使用这种方法，代码的质量要好得多，bug 会更早发现等等，但这仍然值得那笔钱吗？也许我们应该把第二个开发者的薪水付给少数测试员（后者通常比合格的程序员便宜得多）？有没有人有这种比较的经验？

我想避免我的开发人员彼此不分享共同知识（他们遇到的问题的解决方案、酷提示、常见错误、实现特定目标的捷径、配置问题、部分要求等）的情况。我正在考虑这种缺乏沟通是偶然的情况（由于误解或管理不当） - 我没有考虑开发人员故意为自己保留知识的情况。

我相信以下技术对于改进开发人员团队中的信息流非常有用：

• XP 结对编程 - 由于结对内的知识交流（以及由于常规结对混合）。
• 站立会议——因为有机会告诉其他人你在做什么以及你遇到了什么问题。
• 由主要开发人员为团队/部门的其他成员准备的培训/演示/指导。
• “web 2.0 工具”——公司/部门的技术博客、团队负责人的专用 Twitter 帐户、wiki 和类似的东西。

还有什么想法吗？您在公司中使用（或使用过）什么技术？您将如何鼓励开发人员在他们之间分享知识？