微信搜索 【大迁世界】, 我会第一时间和你分享前端行业趋势，学习途径等等。
本文 GitHub https://github.com/qq449245884/xiaozhi 已收录，有一线大厂面试完整考点、资料以及我的系列文章。
本文介绍了“上下文切换”的概念以及它所带来的心理成本。当程序员在复杂的编程任务中进行“上下文切换”时，重新回到之前的工作状态比“简单”的中断更具挑战性。这是因为要完全转换到其他任务，需要清除缓存（短期内存）并加载整个新的上下文。这需要时间、精力，更需要思维的转换。
上下文切换在编程工作中是一个非常常见的问题，这可能会导致更长的工作时间、更低的工作效率以及更高的错误率。这是因为每次切换上下文时，程序员必须重新适应当前任务的上下文和状态。这种转换需要一定的思维和精力，也需要较长的时间来适应新的上下文环境。
为了减少上下文切换的影响，文章提供了一些实用的建议。例如，要尽可能避免中断，让程序员有更多的专注时间来完成任务。此外，可以通过合理规划工作任务的时间和优先级，减少上下文切换的频率。
总之，上下文切换可能会带来不良的心理成本，降低程序员的工作效率和生产力。因此，程序员应该尽量避免中断和上下文切换，合理规划任务，提高工作效率。
中断的成本
根据各种科学研究，打断后需要至少10-15分钟才能重新进入“状态”（Parnin:10，vanSolingen:98）。根据任务的复杂性和你的精力，可能需要超过15分钟：
如果在你手头有很多球——多个未完成的代码片段以复杂的方式拼接在一起——时发生了中断，那么重新进入流动状态可能会更具挑战性。这个概念对每个程序员来说都是众所周知的，但可能只有少数人听说过《两个钟表匠的寓言》，它以易于理解的形式完美地捕捉了所有这些细节，即使对于非程序员也是如此。
曾经有两个名叫霍拉和坦普斯的钟表匠，他们制作非常精美的手表。他们工作室里的电话经常响个不停，新客户不断地找上门。然而，霍拉繁荣昌盛，而坦普斯却越来越贫穷。最终，坦普斯失去了他的店铺。这背后的原因是什么？
手表由大约1000个零件组成。Tempus制造的手表设计得这样，当他不得不放下一个部分组装好的手表时，它立即会散落成零件，必须从基本元素重新组装。Hora设计他的手表，使他可以组装每个子组件约有十个零件，并且每个子组件可以放下而不会散开。这些子组件中的十个可以组装成一个较大的子组件，而这些较大的子组件中的十个则构成了整个手表。
在复杂的编程任务之间切换时，通常比从“简单”的中断返回到流状态更具有挑战性。完全切换到其他事物需要清除缓存（短期记忆）并加载全新的上下文。这个过程需要时间、精力和心力，这是有限的，并且会在一天中逐渐消耗。这些硬性限制是由人类大脑所施加的。
当你分心时，整个舞台都会崩溃，需要花费力气从头开始重建。然而，有一些方便的技巧可以更快地重建它。
重建上下文
对于程序员来说，在任务切换后重新构建上下文通常涉及返回到先前编辑或调试的旧代码。在开始编辑之前，程序员需要导航到几个位置来重建上下文。然而，如果IDE不记住先前的工作状态，任务恢复可能会变得更加痛苦。这通常意味着：
- 最近打开的文件
- 每个打开的文件的光标位置（行和列）
- 断点、监视变量和表达式
- 窗口位置与相同布局（包括选项卡的分割）
手动在 IDE 中重建最后一个工作状态通常是一项真正痛苦和具有挑战性的任务。
失去这个功能会让我的工作流程受到难以想象的干扰。这些打开的文档对我来说代表着一个“书签”，如果没有它们，我几乎无法继续工作。
每次这种情况发生时，我都愿意花费数小时来寻找解决方案，因为在工作会话后再次丢失我的打开文档状态的想法令人恐惧。但这一次，通常的解决方法都没有帮助......这又增加了20分钟，而且还在继续，以解决这个问题我已经花费了两个小时。
程序员非常清楚这个问题：
这是一个比听起来更严重的问题，因为你需要使用其他方法来记住你正在处理的事情。这会导致很多时间的浪费 - 来源。
不得不一遍又一遍地固定同样的标签页真是太令人沮丧了（我想你明白了）。 (...) 我的生产力下降了，压力却上升了！- 来源。
这就是为什么，保存工作状态的能力现在被认为是每个好的 IDE 的基本功能。然而，这并不总是这样。Vim 在大约1998年的v5.2中引入了 :mksession 命令。
一个会话(Session)保存了所有窗口的视图以及全局设置。您可以保存一个会话，当您稍后恢复它时，窗口布局看起来相同。您可以使用会话(Session)快速在不同的项目之间切换，自动加载您在该项目上最后工作的文件。
640 x 480 分辨率是从 1990 年到 1996 年左右的标准，但当时可以获得更多的屏幕空间。有一张著名的照片显示 John Carmack 在 1995 年使用一台 28 英寸 1080p 显示器开发 Quake。
他为什么在1995年花费约10,000美元选择了一个重达45公斤的显示器？更高的屏幕房地产允许一次显示更多的代码，从而产生更密集的上下文。当你有能力存储和访问更详细的上下文时，生产力大大提高。这就像在备考考试或执行需要使用来自共同领域的多个信息源的任何任务时，拥有更大的桌子来存放文件一样，例如解决难题。
我仍然记得在90年代初使用Amiga 1200工作，使用HiRes分辨率（640x256），并使用CygnusED编辑器编写C代码。
此屏幕一次只能打开一个文件，并且它的可用空间不如我的主要4K显示器这些天那么大。从开发者的角度来看，显示分辨率的影响和进步对日常生产力的影响是巨大的。让我们尝试定义这个观察结果。
上下文密度法则
更大的屏幕空间自然会带来更广阔的背景。
为什么程序员能够访问他们最后的工作环境如此重要？让我们从约翰·A·米查姆（John A. Meacham）对前瞻性记忆的定义开始：
前瞻性记忆类似于在冰箱上张贴一个便条，提醒你下班后买牛奶，或者将重要文件放在出口门附近，以便第二天早上离开时不会忘记它。
最后的工作环境是一种前瞻性记忆任务，因此恢复失败也是前瞻性记忆失败（Dodhia:05）。您是否曾经尝试过仅通过记忆来记住购物清单？这可能是一场噩梦，除非您知道如何正确地做（例如，通过可视化技术）。即使是一个简短的清单也很难记住。这就是为什么我们不断通过存储一些信息来帮助我们的前瞻性记忆，就像锚一样。当您早上进入您的（远程）办公室时，会有视觉锚点自动触发您前瞻性记忆的某些区域，例如需要浇水的花或需要在今天处理的桌子上的文件。打开IDE会启动另一组锚点来启动与前瞻性记忆相关的任务。
虽然现代集成开发环境（IDE）在记忆上次工作状态方面表现得相当不错，但它们通常缺乏轻松切换状态的能力。有一些例外。Vim通过 :mksession ，Emacs通过不同的包支持会话，Qt Creator具有类似的功能，基于IntelliJ的IDE通过任务和上下文支持。
代码部署后可能存在的BUG没法实时知道，事后为了解决这些BUG，花了大量的时间进行log 调试，这边顺便给大家推荐一个好用的BUG监控工具 Fundebug。
原文：https://contextkeeper.io/blog/the-real-cost-of-an-interruptio...
交流
有梦想，有干货，微信搜索 【大迁世界】 关注这个在凌晨还在刷碗的刷碗智。
本文 GitHub https://github.com/qq449245884/xiaozhi 已收录，有一线大厂面试完整考点、资料以及我的系列文章。
