为什么开发者如此排斥上下文切换

开发人员在处理上下文切换时会遇到困难。

想知道人们正在面临什么困难，就去看看表情包吧。

笑话源于共识（或者至少源于共同的认知），所以如果你发现某个梗图在流传，它很可能是在描述一群人共同的痛点。

因此，网上有很多表情包和漫画描绘了开发人员遭受干扰和上下文切换之苦，也就不足为奇了。

每位开发者都会告诉你，工作过程中被打断绝对是效率杀手。这并非纸上谈兵。我们最近开展的 Livecycle 协作研究发现，近 50% 的开发者在当前的工作流程中正深受此问题的困扰。

过去一年多的时间里，我作为Livecycle的产品营销主管，一直在研究开发团队协作，令我惊讶的是，在这方面，该系统基本上是注定要失败的。

以以下事件序列为例，它说明了许多开发人员面临的常见工作流程困境：

1. 开发人员正在处理任务 1。
2. 开发人员完成任务 1 并将其合并，以便其他利益相关者可以进行审核。
3. 开发人员继续执行任务 2。
4. 任务 1 的评审意见打断了开发人员当前对任务 2 的专注。
5. 开发人员的上下文从任务 2 切换回任务 1，这影响了两个任务的质量和进度。这是典型的“离不开他们，又无法忍受他们”的情况。

一方面，开发人员必须有灵活性，以便专注于当前任务。另一方面，任何任务的完成都需要其他利益相关者的后续审查。这些​​审查通常会转化为评论、问题，并最终导致开发人员在转而处理其他任务或项目时受到意想不到的干扰。

这只是每天都会发生的众多工作流程场景之一，这些场景都会对开发人员的生产力和产出产生类似的影响。

此时，正在阅读本文的开发者们可能正在点头表示赞同。而那些非开发者们可能会想——那又怎样？这难道不是开发者的问题吗？这跟我有什么关系？

必须认识到，开发人员的问题，从本质上讲，也是产品和整个公司的问题。

事实上，根据麦肯锡最近的一项研究数据，消除开发工作流程中的摩擦点，从而提高“开发速度”，能够直接、积极地影响所有垂直市场企业的最终盈利。

所以这不仅仅是开发人员的问题。对于所有开发团队和企业来说，这都是一个至关重要的根本性问题，必须正面应对。

为什么上下文切换对开发者来说如此痛苦

为了有机会解决这个问题，我们需要首先更好地了解造成这个问题的原因。

为了更好地理解问题的根源，让我们借用保罗·格雷厄姆在 2009 年的一篇博客文章中推广的“创造者与管理者”框架。

保罗写道：

“程序员如此讨厌开会的原因之一是他们的时间安排与其他人不同。开会会让他们花费更多时间。”

日程安排有两种类型，我称之为管理者日程表和执行者日程表。管理者日程表是为老板准备的，它体现在传统的预约簿中，每天被划分成一个个一小时的时间段。如有需要，你可以为某项任务预留几个小时，但默认情况下，你每小时都会更换工作内容。

当你这样安排时间时，与人见面就只是一个实际问题。找到你日程表上的空档，预约一下，就搞定了。

大多数有权势的人都按照经理的日程安排工作。这是指挥的日程表。但还有另一种时间利用方式，这种方式在程序员和作家等创造型人才中很常见。他们通常更喜欢以至少半天为单位来安排时间。你不可能以小时为单位进行高质量的写作或编程。一小时的时间甚至不够你开始动手。

如果你按照“生产者”的节奏工作，开会简直就是一场灾难。一个会议就能浪费整个下午，因为它会把下午分成两段，每一段都太短，根本没法做任何实质性的工作。而且你还得记得去开会。这对“管理者”来说就不是问题了。他们总觉得下一小时还有事要做，唯一的问题是做什么。但对于“生产者”来说，开会就得好好想想了。

对于一个工作日程安排得满满当当的人来说，开会就像抛出一个异常。它不仅会让你从一项任务切换到另一项任务，还会改变你的工作模式。

格雷厄姆认为，生产者和管理者完全不在一个频道上。试图将两者融合在一起，必然会引发紧张和摩擦。

我们可以使用同样的分类方法来理解上下文切换的固有问题。

当另一位利益相关者向一位活跃的开发人员提出问题，或对先前提交的任务提出审查意见时，这两位同事可能正在进行一场对话，但他们肯定说的不是同一种语言。

打断开发人员的人是以“管理者”的身份行事。他认为某个特定的任务或问题需要单独处理，仿佛它只是冲刺结束前待办事项清单上的又一项而已。

然而，对于开发者而言，这种角色转换意味着从创造者模式到管理者模式的根本性转变。正是这种转变（及其持续影响）引发了所有个人、职业和技术方面的紧张关系，而这些紧张关系最终都会成为我们在那些行业笑话梗图中津津乐道的内容。

应对上下文切换危机的两种方法

这种“创造者与管理者”的框架也有助于我们理解为解决这种矛盾而提出的众多方案。因为在分析过去几个月提出的解决方案时，我认为所有建议都可以归纳为两大类。

“管理模式”方法

第一种方法我称之为“管理模式方法”。这种方法通过接受问题的本质并采取补救措施来解决开发人员的上下文切换问题。

这种方法承认开发者需要在整个工作流程中不断切换创建者模式和管理者模式，而这可能会带来一些成本。但我们可以通过一些表面上的效率提升技巧和日程安排方法来限制这种不尽如人意的现实带来的影响。

我最近在Reddit上看到一个关于“开发者上下文切换——技巧与窍门”的帖子，里面列出了一些具体的建议。评论中的所有建议都完美契合了“管理者”的方法：

在日程表中积极安排集中工作的时间段。

• 在 Slack 中隐身，关闭电子邮件等等。
• 关闭 Slack 中的音频通知
• 使用“StayFocused”Chrome扩展程序屏蔽所有社交媒体网站等。
• 使用 Brain.fm 可以播放非常适合集中注意力的音乐。
• 设立“无会议日”
• 阅读像《搞定一切》这样的提高效率书籍

以上建议固然不错，但它们对开发者和开发团队却有害，因为它们假定我们需要生活在（和工作）一种持续的紧张状态中，并且暗示开发者在某个时候需要转型为管理者。就开发工作流程而言，这些建议与其说是解决实际问题的真正方案，不如说是权宜之计。

“创客模式”

这就引出了处理开发过程中上下文切换的第二种方法：“创客模式”方法。

创客模式退后一步，以更全面的方式重新评估现状。它默认开发者应被赋予权力，尽可能长时间地保持“创客模式”。这是应该维持的现状。如果工作流程的任何部分需要进行创新性修改，那应该是我们收集和处理其他利益相关者反馈的方式。或许我们可以找到一些不那么干扰开发者的方式，让他们参与到评审过程中，而不会直接影响开发者专注于当前任务的默认需求。

这听起来可能好得难以置信。但这正是我们在构建 Livecycle 时所采取的方法。

Livecycle 如何实现“管理者”模式

在分析这些问题时，我们意识到“拉取请求”（Pull Request）是一个可以更好地利用的工具，它是实现更优化工作流程的关键。实际上，每个拉取请求都是由开发人员发起的，表示“准备审核”。开发人员实际上是在向其他开发人员征求反馈意见，然后再将代码更改合并回“主”分支。

我们看到了一个机会，可以利用这个时机，通过自动创建一个可共享且隔离的环境，让团队中的几乎每个人都能自行体验最新的变化，从而将所有相关的利益相关者都纳入其中。

构建并托管代码更改的代表性版本，并与更多利益相关者共享，是实现更具包容性的 Pull Request 工作流程的第一步，该工作流程既能让其他人参与其中，又能让开发人员腾出手来处理其他任务。

然后我们再进一步。

我们不仅为每个 PR 提供供其他利益相关者使用的预览环境“试验场”，还在试验场之上添加了注释层，以便所有相关协作者都能在产品 UI 之上，以他们各自的上下文留下清晰的评论。此外，我们不仅在 Livecycle 中整理所有这些反馈，还会将其同步回 Git，以便代码所有者在准备好时进行审查和处理。

我们以“应该尽可能长时间地让开发者处于‘创造者模式’”为基本假设，从而能够采取更具创造性和更根本正确的方法来解决上下文切换问题。

因此，使用 Livecycle，我们上面概述的问题工作流程现在看起来会像这样：

1. 开发人员正在处理任务 1。
2. 开发人员完成任务 1 并将其合并，以便其他利益相关者可以进行审核。
3. 开发人员继续执行任务 2。
4. 任务 1 的评审意见会即时异步收集，不会干扰开发人员当前对任务 2 的专注。
5. 开发人员可以完成任务 2（或在合理的停顿点暂停），然后将注意力转移到解决任务 1 的所有问题上，并在合适的时间进行。

我们更具包容性和协作性的公关方式能为团队带来诸多立竿见影的好处：

• 减少上下文切换 → 合并功能分支后，您就可以彻底地继续执行下一个任务了。
• 即时收集反馈意见 → 随时控制并邀请您需要的反馈（就像您向其他开发人员请求代码审查一样）
• 减少分支的歧义并保持清晰的 Git 结构
• 自动为公司所有利益相关者的所有必要功能变更创建审计跟踪。
• 始终保持可复现环境，确保每次提交都能重现问题 → 让你的 SCM 成为应用程序的时间机器。

这种“创造者”模式最大的优势或许在于它保留（并放大）了每位参与者的自然状态。程序员可以专注于编码，其他利益相关者（他们可能更倾向于“管理者”的工作方式）则可以更高效地完成评审工作。而且，所有参与者都异步工作，从而避免了不必要的干扰和工作切换。

趁现在还能看到这些表情包，好好享受吧……