开发人员在任务之间切换最有效的方式是什么？
我正在寻找从一个软件开发任务切换到另一个软件开发任务时执行的一系列步骤的工作流程类型描述。如果某个步骤涉及工具，请指定哪个工具及其使用方式。工作流的目标是从任务#1 到任务#2，再回到任务#1 尽可能顺利地过渡。
考虑这个场景...
- 您正在实现一个新的用户故事，虽然今天到目前为止已经取得了进展，但它还没有完全完成，而且您还没有实现测试。
- 您的领导向您带来了一个高优先级的错误，该错误阻碍了您的测试团队。您需要停止正在做的事情并修复错误。该错误存在于三天前的版本中，这是测试团队发现的最新版本。
您可以在新版本的源代码中修复该错误，但它必须是稳定的版本，并且不能包含您当前正在开发的不完整功能。
I'm looking for a workflow-type description of the series of steps you perform to switch from one software development task to another. If a step involves a tool, please specify which tool and how it's used. The goal of the workflow is to have the smoothest possible transition from task #1 to task #2 and back to task #1.
Consider this scenario...
- You're implementing a new user story and, while you've made progress so far today, it's not quite done and you haven't implemented your tests yet.
- Your lead comes to you with a high priority bug that's blocking your test team. You need to stop what you're doing and get the bug fixed. The bug is in a build from three days ago, which is the most recent build the test team has picked up.
You can fix the bug in a new version of the sources, but it has to be a stable version and can't include the incomplete feature you're currently working on.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
Alt + Tab 就是我们的做法。
Alt + Tab is how we do it.
任务切换是大脑的事情。我认为没有工具可以为您做到这一点。如果有的话我也有兴趣。
每个人都有自己的准备方式，有些人根本不准备，而是像快照一样做另一件事，有些人需要更多时间等等。这取决于男人/女人。
当然，你可以尝试创建一些心理里程碑（记笔记、设置提醒等），以便在返回任务时返回到它，但这又取决于其他因素（任务切换多长时间、办公室有多安静） ，熟悉任务，月相等）。
我认为开发人员在任务之间切换的最有效方法是主观的。
同时，您是否阅读过 Joel Spolsky 的人类任务切换被认为有害？
Task switching is a thing of the brain. I don't think there is a tool to do that for you. If there is, I am also interested.
Each person has its own way of preparing, some don't prepare at all and are in another thing like a snap, some take more time etc. It depends on the man/woman.
Sure, you can try to create some mental milestones (taking a note, place a reminder etc) to return to it when getting back to the task, but this again depends on other factors (how long was the task switch, how quiet the office, familiarity with the task, moon phases etc).
The most efficient way for a developer to switch between tasks I think is subjective.
Meanwhile, have you read the Human Task Switches Considered Harmful from Joel Spolsky?
我想说，在您描述的场景中需要采取的步骤 100% 取决于您设置的开发环境和工具。
使用 Perforce 进行源代码版本控制，我们建立了一个分支系统，其中版本与开发工作分开，所有开发分支都源于单个“接受”分支。每个分支用于单个问题或一组非常密切相关的问题。在更改被集成到验收分支之前，不能在分支中处理其他问题。
是的，这确实意味着我们有很多分支机构。是的，我们做了很多同步（验收到工作分支）和集成（工作分支到验收）。但是，当涉及到轻松地从一项任务切换到另一项任务、返回到测试构建、发现两个相互咬合的问题等时，它的价值是不可估量的。
在开发完成其工作（包括他们自己的测试）后，一个问题是由 QA 团队测试。首先在自己的分支中隔离。之后，将其集成到验收分支中，并进行回归测试，以发现任何相互影响的独立问题。当发布的所有问题都已纳入验收时，质量检查团队将执行完整的回归和新功能测试。
因此，接受分支始终是应用程序的“最新”开发状态。
在此设置中，您描述的场景将如下所示：
保留我当前的任务不变，可能会签入任何未完成的更改，以免在计算机崩溃时丢失它们。如果这意味着破坏该分支的日常构建，我不会签入，除非很容易修复编译错误。 （请注意，我们的应用程序套件中有许多应用程序，虽然我的更改可能会在我正在开发的应用程序中编译，但它们仍然可能会破坏我们套件中其他应用程序的编译）我们的规则是：每次提交都可能会破坏功能，但是不得破坏构建过程。
查找一个“空”分支 - 当前未用于任何开发工作的分支，或者，如果所有分支均已使用，则创建一个新分支。
查找一个“空”分支
强制同步接受分支和选定的工作分支，以便保证我的机器具有两个分支的最新状态。
强制同步接受分支
同步（必要时强制）验收分支的最新状态到工作分支，因此所选工作分支与验收分支相同。
在 IDE 中打开该分支的应用程序套件，进行调试和解决。提交到工作分支。
告诉 QA 在工作分支中查看它。如果他们对此感到满意，请将更改集成到接受状态，以便他们可以继续测试。
将 IDE 切换回我之前处理的分支中的应用程序套件。
冲洗并重复。
I would say the steps you need to take in the scenario you describe are 100% dependent on the development environment and tools you have set up.
Using Perforce for source code version control, we have set up a branching system where the releases are separate from development work and all development branches stem from a single "acceptance" branch. Each branch is used for a single issue, or for a set of very closely related issues. No other issues can be worked on in a branch until the changes have been integrated up to the acceptance branch.
Yes, it does mean we have a lot of branches. Yes, we do a lot of syncing (acceptance down to a work branch) and integrating (work branch up to acceptance). But its worth is incalculable when it comes to easily switching from one task to another, going back to a test-built, spotting two issues biting each other, etc.
After development has done its thing (including their own tests), an issue is tested by the QA team. First in isolation in its own branch. After that is is integrated into the acceptance branch and a regression test is done to find any problems with independent issues biting each other. When all issues for a release have thus been integrated into acceptance, a full regression and new functionality test is executed by the QA team.
So, the acceptance branch is always the "latest" state of development for the app.
In this set up the scenario you describe would play out as:
Leave my current task as it is, possibly check in any outstanding changes so as not to lose them when my computer crashes. If that means breaking a daily build of that branch, I wouldn't check in, unless it is easy to fix the compile errors. (Please note that we have many apps in our application suite and while my changes may compile in the app I am working on, they may still break the compilation of other apps in our suite) Our rule is: each submit may break functionality, but must not break the build process.
Find an "empty" branch - a branch that is not currently being used for any development work, or, if all branches are taken, create a new one.
Force sync the acceptance branch and the selected work branch so my machine is guaranteed to have the latest state for both branches.
Synchronize (forced if necessary) the latest state of the acceptance branch to the work branch, so the selected work branch is the same as the acceptance branch.
Open up that branch's application suite in the IDE, debug and solve. Submit to the work branch.
Tell QA to have a look at it in the work branch. If they are satisfied with it, integrate the changes up to acceptance so they can continue their test.
Switch the IDE back to work on the application suite in the branch I was working on before.
Rinse and repeat.
考虑到您的情况，
您可以在另一个工作副本中查看源代码的稳定版本，纠正错误，然后提交。
当你回到未完成的工作时，进行更新并继续工作。
Considering your scenario,
you could check out the stable version of sources in another working copy, correct the bug, commit.
When you come back to your incomplete work, do an update and continue to work.
当你在做某件事时，你通常会有一些想法，一些你计划做的事情，一些不清楚的事情，必须稍后解决。当您切换到其他任务时，它往往会丢失。
我发现把它们写下来很有用——拍一张大脑快照。稍后可以更轻松地恢复它并更快地返回到原来的任务。
When you're working on something you usually have a few ideas, few things you're planning to do, some stuff that is not clear and has to be solved later. It tends to get lost when you switch to other task.
I found it useful to write them down somewhere - take a brain snapshot. Later it's easier to restore it and get back faster to your original task.
我在任务/待办事项中记录了我正在处理的每个文件，并在大约 1 秒内进行提醒。我将离开它的时间。然后我保存并关闭每个文件，以防止它们分散我的注意力/消除混乱/为桌面上的新任务创建空间。我有跳蚤的记忆力，所以我需要所有我能得到的帮助。
I make a note of every file I'm working on inside of a Task/Todo item with a reminder in approx. the amount of time I will be away from it. Then I save and close each of those files to prevent them from distracting me/eliminate the clutter/create room for the new task on my desktop. I have the memory of a flea, so I need all the help I can get.