上下文切换给开发团队带来的隐形成本

Incredibuild 官方账号

于 2024-06-11 10:20:12 发布

阅读量1.1k

点赞数 17

分类专栏： C++ 文章标签： c++ ci/cd

本文链接：https://blog.csdn.net/incredibuild/article/details/139591697

版权

168 篇文章 9 订阅

订阅专栏

在这里插入图片描述

所有人都明白开发人员最不喜欢工作中被打断。低头，戴上耳机，神情专注。如果你问他们一个问题，他们会略显困惑，因为他们在想你是谁，为什么你不是一行代码。

开发工作的大部分是深度工作，需要全神贯注。进入和退出这种状态都需要时间，这就是为什么大多数开发人员不喜欢被打扰。

但对许多开发人员来说，工作中被打扰是常态。会议、紧急支持工单、电子邮件、同事的随意提问，开发者的一天充满了干扰。每一次干扰都会付出代价，削弱开发者的生产力、工作质量和心理能量。

我们称这种从一个任务跳到另一个任务的现象被称为“上下文切换”，即使这个概念不被熟知，但它可能正在破坏开发团队的输出质量。

上下文切换意味着从一个任务转移到另一个不相关的任务。

换句话说，它迫使你的大脑从一个项目或工作类型跳到另一个。这是开发人员从编码任务中抽离出来参加一个小时会议的时刻，迫使他们的大脑从“深度专注”模式切换到“人际讨论”模式。

上下文切换并不总是涉及像这些这样的重大干扰，它可以由一个简单的 Slack 消息或同事的随意问题引发。

开发人员总是需要进行一些上下文切换，无法完全根除它，只有当被干扰的问题无限制增加时才会成为问题。当开发人员每周甚至每天都在努力争取他们需要的时间来完成开发的工作时，它才会成为问题。

有一些结构性问题可能会导致这种情况。

超负荷的工作量。超负荷的开发人员发现自己被拉向了上百个不同的方向，当日常工作情变得太忙时，优先级可能会被抛到一边；开发人员常见的状态是在许多不同的任务上取得渐进进展，而不是一次完成一个重要任务。
太多会议。很容易看出一个两小时的会议如何削减开发人员的生产时间，但你知道更糟糕的是什么吗？一个在四小时深度工作中突然出现的“十五分钟更新”。当开发人员准备好会议，参加会议，然后重新集中注意力时，开发人员可能只剩下大约两小时的实际工作时间。

这些问题会让开发人员脱离他们的工作，但解决它们的办法相对明确：开发人员需要更易管理的工作量、更长的时间表和更高效的工作方式。解决这些问题可能并不简单，但自从“倦怠”这个词第一次进入我们的词汇以来，我们就一直在思考这些问题。

但上下文切换最常见的原因要复杂得多，开发人员上下文切换的原因往往不是因为他们需要承担另一项重要任务，他们上下文切换是因为他们无法在当前构建上继续工作。

想象一下：一个开发者正在处理一个重大项目，深入研究代码的细节，花了数小时，他这时感觉精力充沛，灵感涌现。

当构建开始运行。有时，构建足够快，可以在它运行时继续工作，比如可以发送几封电子邮件或完成一个快速的低能量任务，很快回到主要任务上来。

但大多数构建不会运行得那么顺利，我们的“大开发构建时间”调查报告发现，开发人员平均每天花57分钟等待构建完成。

当你被这些长时间的构建困住时，上下文切换实际上似乎是个好主意。事实上，开发人员会觉得自己特别高效，比如你会想，“我可以利用那段失去的时间来完成待办事项清单上的其他任务，而不是盯着天花板或去泡我的第十五杯咖啡。”

问题在于，上下文切换并不能真正解决长时间构建的问题。如果有的话，它会放大浪费的时间。

在当下，上下文切换通常感觉相当高效，但你在新任务上花费的每一刻都会让你更难回到原来的任务中。

一项研究发现，上下文切换后平均需要23分15秒才能回到手头的原任务。这个数据适用于任何职业，但对于那些花大量时间在深度专注工作上的开发人员来说尤其如此。

想象一下，你整天定期暂停等待构建。这样做六次左右，你在八小时的工作日里就损失了将近三小时。根据 StackOverflow 的估计，开发人员的平均时间成本为每小时83美元，这仅上下文切换就几乎每天每个开发人员损失250美元。

这并不止于此。一些较早的研究估计，被打断的任务花费的时间是未被打断任务的两倍，并且错误数量可能是未被打断任务的两倍。而这只是上下文切换对业务的影响。研究表明，持续的上下文切换会损害开发人员的心理健康。

在加利福尼亚大学的一项调查中，受到更频繁打断的开发人员更容易感到压力和沮丧。他们试图通过更努力和更快地工作来弥补打断——但在此过程中，削弱了他们的心理健康并引入了更多错误。而更多的错误意味着更多的压力……

换句话说，如果你的团队利用长时间的构建来完成其他任务，你就走错了路。

如果开发团队真的想提高生产力，需要解决根本问题。需要加快构建时间，以便尽可能减少上下文切换。

以此为目标，开发团队应该考虑三个关键方法：

尝试构建缓存。通过在临时位置存储多个构建输出和工件的副本，可以在以后的软件构建中重复使用关键组件。构建缓存意味着每次启动构建时都不再从头开始。将简化整个软件开发工作流程，更有效地使用资源，甚至更快地解决错误。
编写对构建友好的代码。使代码编写更快的捷径可能会减慢构建速度，开始评估你的代码，看看是否有机会减少依赖项，使用编译器简化代码功能，或使用预编译头文件。
明智地使用硬件和资源。可以通过增加额外的硬盘、CPU、服务器和内存，或增加云资源来加快构建速度。但要小心，这种方式的扩展成本可能会迅速增加。如果想在控制成本的同时加快构建速度，最好找到更有效利用现有资源的方法。这可能意味着探索启用分布式构建、成本效益高的云资源管理，或其他一系列调整，以帮助实现较高的投入产出比。