Questions tagged «pair-programming»

结对编程是一种敏捷的软件开发技术，两个人在一个终端上一起工作。虽然第一人称专注于语法和其他战术方面，但其他人则从更大的上下文角度审查了代码。

7
配对编程什么时候起作用？什么时候避免呢？
并非一直在刻苦地配对编程，而是在团队中选择性地使用配对编程。我认为在以下情况下效果最佳： 加强项目中全新的团队成员（而不是让他们自己浏览文档或代码）。 初级和高级人员一起工作（有助于显示经验丰富的开发人员的一些技能和技巧，此外，它还允许老狗有时学习新的技巧）。 当某人试图查找缺陷时，通常可以帮助您与另一只眼睛配对。 什么时候使用配对程序，为什么？ 什么时候避免成对编程？为什么？
6
敏捷与XP有何不同？
我在网上阅读了几篇文章，以了解敏捷，XP，Scrum，结对编程之间的区别/彼此之间的相互关系，并得出以下结论： Scrum和XP几乎相同。XP的发布时间比Scrum短 敏捷和XP方法中都采用了结对编程 但是我无法确定敏捷与XP有何不同。 除了提供URL，我将很高兴阅读您对此的经验和想法。
6
当驾驶员和观察员具有不同的技能水平和经验时进行配对编程
我知道结对编程是一种敏捷的软件开发技术，其中两个程序员在一个工作站上一起工作。一个是驱动程序，编写代码，另一个是观察程序，查看键入的每一行。 但是我只是想知道这种策略在这种情况下是否仍然有效。例如 如果他们有非常不同的编程技能水平。 如果一个人从未在问题领域经历过，而另一个人则在经历过。 如果他们的编程技能水平低，还可以吗？ 您能建议上述情况下的结对编程策略吗？
11
如果需要结对编程，我应该接受工作吗？[关闭]
给我提供了一份有趣的工作，但是对我来说有一个很大的警告：他们使用结对编程。 我讨厌结​​对编程的想法，但我可能不适合这样做：我喜欢经常停顿，我不想看到有人编程（我会不断戳一下结对以自己编写代码），我必须全力以赴控制我正在使用的机器，我喜欢听音乐，基本上我不喜欢被别人束缚。我什至不是一个社交人。 但是，我从来没有真正使用过真正的结对编程（短时间几次来帮助别人或一起解决一个复杂的任务）……所以结对编程真的那么糟糕吗？考虑到我的态度，我应该拒绝工作还是应该离开目前的工作去尝试？ 对于那些问这个问题的人：我正在寻找一个使用正式设计和开发的工作，因为我讨厌我目前在“野外编码”的工作。该公司对我的技术资料非常感兴趣，因此即使我指定我从未从事结对编程工作，他们仍然坚持认为我可能会不喜欢它（除了是一个不友好的独来独往的程序员，我不喜欢并相信配对编程）。
7
结对编程可能有哪些缺点？[关闭]
已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 3年前关闭。 结对编程在当今非常有名。 它具有以下优点： 错误较少的程序。 后期制作维护成本要少得多。 既定的做法受到挑战，导致出现新的想法。 程序员可以互相学习。 程序员发展软技能。 但是结对编程的缺点是什么？
6
在一家小公司中进行编程/协作配对
我在一家小型开发公司工作，担任首席开发人员。我们还有另外两个开发人员，还有我的老板，他是一名开发人员，但实际上并没有做太多实际的编码。 我要克服的问题是多方面的。我们之间的趋势是所有人之间都没有太多合作就可以从事我们自己的项目。事实上，我（作为最高级的开发人员）比其他人更愿意寻求他人的意见/帮助，因为我重视外在的想法。 我想加强我们的合作，并向他们表达了这一点。在很大程度上，因为我想向他们展示一些有关如何成为更好的开发人员和遵循更好的做法的事情。但是考虑到我们其他开发人员的个性类型，我认为他们一个人工作更自在。 我一直在阅读关于结对编程的知识，并且我已经（在某些论坛中）读到，当您拥有一个开发人员比其他开发人员更先进时（我是），它不能很好地工作。但是，我觉得我们必须开始合作，以使我们的工作不会如此分散。 我的问题是，是否有人曾经遇到过类似情况，什么对他们有用？ 我意识到这不是万能的，但我愿意尝试多种方法。 我们所有人都在一个公共区域工作，开发人员没有单独的办公室/隔间。
3
在结对编程时如何研究？
最近，我开始了一项新工作，结对帮助我在当地迅速取得了成功。但是，当我们必须在工作流程中进行简短的联合研究时（包括API功能，代码示例或命令选项），我很难受。我的团队负责人敦促我们在配对站上而不是在单个笔记本电脑上进行所有研究，并通过口头协商不同Web资源之间的步骤来同步我们的研究。 我的研究，阅读和吸收信息的方式与配对伴侣不同，并且我可以根据自己的意愿在下一个网页上完全跟踪研究内容，而不是试图与其他人保持准确的步调和位置，从而提高工作效率。我伴侣的阅读。我们既聪明又快速，但是当我们找出问题时，我们不禁以不同的方式和瞬时的速度前进。独自一人闲逛一分钟直到我们中的一个人说“我明白了”，然后重新聚在一起进行编码似乎要容易得多。 配对程序时，如何处理简短的研究任务？什么最适合您，如何与伴侣保持同步？
5
结对编程时如何实现并维持流程？
流是Mihaly Csikszentmihalyi提出的概念；简而言之，它意味着进入“区域”。您会沉浸在工作中，专注于工作；这项任务可能很困难，但同时又充满挑战。当人们实现潮流时，他们的生产力就会猛增。编程需要大量的精神关注，因为我们经常需要一次兼顾脑海中的几件事。许多人喜欢在一个安静的环境中工作，在那里他们可以全神贯注于任务。如果它们被打断，可能要花费几分钟甚至几小时才能恢复正常。 我了解敏捷开发和极限编程中有一种称为结对编程的实践。这意味着您将整个软件开发团队放在一个房间中，以便无缝沟通。您确实要与一对伙伴一起编写代码，因为通过这种方式，您可以立即进行代码审查，并且可以减少更少的错误。 由于不断的中断，在进行结对编程时，我一直遇到实现流程上的问题。我在思考一个问题，然后突然有人问我另一个问题。我的思路迷路了。 结对编程时如何实现并维持流程？
5
配对编程和ISO 27001
我一直在eXtreme编程团队工作，并且在Windows环境中进行结对编程已有7年以上。当我们第一次开始执行此操作时，某人将使用其Windows凭据登录，因此，对该域用户的所有对域资源（尤其是版本控制）的访问都应负责。最终，我们发展为特定配对站（例如，pairA，pairB，PairC等）的窗口配对帐户。所有开发人员都知道这些帐户的密码。通过在提交过程中将程序员的姓名缩写写在注释中，可以实现提交（签入）的责任。 到目前为止，这对我们来说还算不错，但是我公司目前正在通过ISO 27001审核，审核员将其标记为风险。我有许多可能的解决方案，例如为每个配对组合创建一个配对帐户，但我真的很想知道是否有人遇到过这个问题以及他们如何解决？ 审核员可以接受哪种解决方案？
7
结对编程在工作场所有多普遍？
我一直对结对编程感兴趣，但是在12年的开发中，我从未在他们采用这种做法的地方工作过，因此我一直对人们的看法持怀疑态度。 我想知道这是因为金钱/时间（尖头的老板在同一台计算机上发现两个人正在使用相同的代码！！！！！！！！！！他们怎么敢！！）还是其他原因？
9
您如何在配对编程环境中展示性能？
最近我的工作中进行了绩效评估，我的职位很有趣。我们的团队进行了大量的结对编程，这倾向于平均化团队成员之间的技能差异（尤其是考虑到轮换对）。通常，在进行绩效评估时，您会回顾已完成的工作，并展示您已完成的工作以及如何超出期望以协商加薪或其他收益。 您如何在这样的环境中展示（甚至衡量）个人表现？
3
货币互换：利弊是什么？
大多数敏捷 / XP理论家都拥护的一般想法似乎是，对应该定期交换。例如，每个程序员每天应该交换一次对。一半的人在一天开始时进行交换，一半的人在午餐后进行交换：由于会议，假期之类的外部因素，大多数人倾向于每周交换一次或两次交换时间，以便分配配对配置在整个团队中相当平均。 频繁调换的一个基本原理是，知识在团队中快速而均匀地传播，而不是将特定的技能和知识集中在特定的个人身上-这意味着如果人们离开公司或离开公司，工作就可以顺利进行。另一个原理是围绕结对编程本身的教条的一种推论，即每次有人交换您时，都会得到新的视线审查，因此它只能提高代码质量。 两种说法听起来都合理；从管理的角度来看，这听起来好像您在稳定性和质量上都得到了提高，而这种频繁的交换在我所研究的大多数Agile / XP书籍中几乎都是标准理论。 因此，当实际付诸实践时，人们实际上对从 程序员的观点？ 经理的观点？ 和 当某人从/交换到一对时，应如何确定？
1
配对编程是否消除了极限编程（XP）项目中的代码审查需求？
在一个极端的编程项目中，程序员大部分时间都会进行配对编程。 由于这些对也轮换使用，也就是说，您将程序与不同的人配对，并且具有集体所有权感，因此经常对源代码进行检查和更新。 这样的话，是否需要代码审查？我的意思是，停止编程，实际上只是进行代码审查。
2
将编程业务逻辑与非IT人员配对
已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 4年前关闭。 您在编码过程中是否有非IT人员与程序员合作的经验？ 这就像结对编程一样，但是一个人是一个非IT人员，对业务有很多了解，也许是一个具有数学背景的流程工程师，他知道事物是如何计算的并且可以理解非惯用的程序代码。 我发现非IT工程师很容易理解某些过程性领域特定语言，例如PL / SQL。这些人最终成为代码的共同作者，并保证公式，因子等的正确性。 我发现这种成对编程非常有效率，这种工程类型的用户认为他们也是代码的“所有者”和“作者”，并有助于最大程度地减少沟通过程中的误解。他们甚至帮助设计测试用例。 这种做法常见吗？ 它有名字吗？ 您有类似的经历吗？
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.