blocks|key|3470364|text|如果你可以单独做其他事情，为什么结对的时候不行呢？也许更简单的行动项目可以在等待期间从问题列表中删除？3分钟的等待对我来说太长了，无法让大脑保持“心流模式”。所以不管怎样，被打乱了(你的伴侣也是如此)，你就不能和你的伴侣一起做点别的吗？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3470365|然而，在你的情况下，我不会在任何改变后有3分钟停顿的环境中工作。所以问题是:难道你不能在一个较小的环境中开发和调试代码，把它烤得完美，然后把这些片段重新集成到主流中吗？|3470366|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

If you could do something else alone, why not when pairing? Maybe simpler action items could be taken off an issue list while waiting? A 3 minute wait would be too long for me to keep the brain in the "flow-mode". So being disrupted anyway (and your partner as well), can't you just do something else with your partner?

However, in your situation, I'd not work in any environment where I have 3 minutes pauses after a change. So the question is: can't you develop and debug that code in a smaller environment, broil it to perfection and then reintegrate those pieces into the main stream ?

blocks|key|4939356|text|您的里程可能会有所不同，但我认为任何不是主要特性的结对编程都是浪费至少一个程序员的时间|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4939357|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

your mileage may vary, but i consider pair programming on anything less than a major feature to be a waste of at least one programmer's time

blocks|key|1154340|text|结对编程应该只应用于开发的research/POC/innovative部分。简单的任务应该委托给单个程序员。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|1154341|这不仅仅是浪费时间的问题，当你不得不等待你的伴侣完成琐碎但耗时的任务时。还有一个人为的因素--在等待的时候你会感到无聊()。记住，高效的开发人员需要不断地激励--等待你的伴侣完成会降低你的士气。|1154342|entityMap^0|D|N|0|27|I|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|M|8|@$9|N|A|O|B|C]]|D|@]|E|$]]|$1|H|3|-4|5|6|7|P|8|@]|D|@]|E|$]]]|I|$]]

Pair programming should be applied only to the research/POC/innovative parts of the development. Simple tasks should be delegated to the single programmers.

It is not only the problem of the waste of time when you have to wait for your partner to complete the tivial but time-consuming task. There is also a human factor - you get bored while waiting. Remember that productive developer need to be constantly motivated - waiting for your partner to complete lowers your morale.

blocks|key|4939363|text|您可能应该考虑重构流程。对于配对和单独编码来说，三分钟获得反馈都太多了。不断地换档会扼杀你的生产力。你可能只是在配对的时候感觉更好。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4939364|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

You should probably consider refactoring the process. Three minutes to get feedback is too much both for pairing but also for coding solo. It is killing your productivity to have to switch gears constantly. You probably just feel it more when pairing.

blocks|key|3470569|text|性能工作，您必须运行几分钟来收集统计数据，这并不是很适合XP。有一个强有力的理由是，一开始是两个人一起勾勒出一些想法，然后单独行动，以避免在每三分钟的表演中浪费两个人的时间，然后再次加入，在签到之前审查工作。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3470570|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Performance work, where of necessity you must run for a few minutes to gather statistics, is something that isn't a great fit for XP. There's a strong case to be made for starting off as a pair to sketch out some ideas, then going solo to avoid wasting two people's time for every three-minute performance runs, then joining up again to review the work prior to checking in.

blocks|key|1154391|text|性能峰值的时间必须是内置的，而不是附加的。团队应该有一套自动化测试，可以在类似生产的环境中频繁(每天)运行。此外，团队应该持续运行分析器。如果你两者都没有，现在就停下来把它做完吧！|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|1154392|如果团队发现自己处于性能问题的情况下，它需要确定技术债务并创建一组故事卡来解决债务。它将包括一组自动化性能测试，一组分析器测试。每天分析测试结果是必须的。然后，如果出现性能问题，则可以调用架构或设计峰值。|1154393|如果团队从一开始就没有连续地进行性能测试，那么您可能会有大量的技术债务需要解决。一旦你让应用程序运行起来，你就需要每天运行你的自动化测试，这样你就可以意识到什么时候出现了问题。然后，您最好识别出应用程序的违规更改。|1154394|通过运行自动性能测试，您可以允许测试运行一段时间，通常是几个小时。结果可以在以后进行分析，它使开发人员可以在其他故事卡上进行工作，而无需等待大量单独性能测试的结果。|1154395|等待是一个拦路虎。通过自动化测试消除等待。|1154396|entityMap^0|5|2D|0|0|2U|0|0|2Z|0|0|2A|0|0|L|0^^$0|@$1|2|3|4|5|6|7|P|8|@$9|Q|A|R|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|S|8|@$9|T|A|U|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|V|8|@$9|W|A|X|B|C]]|D|@]|E|$]]|$1|J|3|K|5|6|7|Y|8|@$9|Z|A|10|B|C]]|D|@]|E|$]]|$1|L|3|M|5|6|7|11|8|@$9|12|A|13|B|C]]|D|@]|E|$]]|$1|N|3|-4|5|6|7|14|8|@]|D|@]|E|$]]]|O|$]]

Time for a spike Performance has to be built in, not added on. The team should have a set of automated test that can run frequently (daily) in a production like environment. Also, the team should be running a profiler continuously. If you don't have either, time to stop the line and get it done now!!!

If the team finds itself in a situation where performance is an issue, it needs to identify the technical debt and create a set of story cards to address the debt. It would include a set of automate performance test, A set of profiler tests. Daily analysis of the results of the test is a must. An architectural or design spike can then be called should a performance issue present itself.

If an team has not been doing performance testing continually from the start, you could have a significant technical debt to address. Once you have the application performing, you need to keep running your automated testing daily so you can become aware if and when a problem arises. You are then better to identify the offending changes to the applications.

By running automated performance test, you can allow the test to run for some period, generally for a period of hours. The results can later be analyzed and it frees the developers to do work on other story cards without waiting for the result of numerous individual performance tests. 

Waiting is a blocker. Eliminate waiting via automated tests.

blocks|key|1154433|text|不管你是不是结对编程，这都没关系。3分钟对于获得代码更改的反馈来说太长了，即使你单独编码也是如此。我会分析和分解这个项目，这样我就可以专注于更小的部分。从这个意义上说，XP实际上是在帮助(迫使)您在为时已晚之前改进设计。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1154434|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

It doesn't matter if you are pair programming or not. 3 minutes is way too long for getting feedback on code change even if you are coding alone. I would profile and break down the project so that I can focus on a smaller pieces. In that sense, XP is actually helping(forcing) you to improve the design before it's too late.

blocks|key|4939633|text|我会为这些任务分头行动。你们两个分别处理代码，并且经常重新组合(30分钟左右？)当你做了改进的时候。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4939634|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I would split up for those tasks. Both of you work on the code separately, and recombine every so often (30 minutes or so?) when you've made improvements.

I work in an Extreme Programming team, pair programming every day. Recently more and more often I get to do stuff that gives slow feedback, on order of 3 minutes. For example: change some thing, recompile, run and see wheather the performance is improved. I see it coroding the quality of pair programming, and I think it affects pairs more that solo programmers. If I am alone I can do sth else, but what if I am pair programming? How would you deal with it?

How to cope with slow feedback when pair programming?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

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

问如何处理结对编程时反馈缓慢的问题？
EN

回答 8

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何处理结对编程时反馈缓慢的问题？EN

回答 8

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何处理结对编程时反馈缓慢的问题？
EN