上下文切换的费用超过了我们的功劳

当我是一名初级工程师时，我从一位经验丰富的首席工程师那里得到的最好建议之一就是对事物进行批处理，按照优先顺序（按时间，大小，影响或优先级）对它们进行排序，然后执行。并且，在批处理它们时要小心。按功能对它们进行批处理可提高生产率，因为它可以最大程度地减少上下文切换成本。

当时，我没有特别注意该建议，因为我认为我可以很好地完成多任务。因此对我来说，上下文切换的成本已经很小。我不需要按功能划分任务。我可以开车去听广播。我可以清洗餐具并看电视。而且我可以吃东西并进行交谈。

对于你们中的许多人来说，很明显，功能已经可以分隔上述任务。即使我正在执行多任务，这两个任务也被牢固的功能边界（即身体和精神）分开，上下文切换的成本已经大大降低了。

但是，当涉及到工作，特别是工程工作时，多任务处理的成本就飞涨了。因为（对于软件工程师）所有任务都属于认知功能。结果，它需要很多上下文切换。

尝试编码和听音乐属于认知功能。在聆听自己喜欢的歌曲时给变量命名＆＃39;歌词可能会导致认知超负荷。与歌手/歌曲的名字相比，您更可能使用一个变量来命名该变量，而不是该变量所反映的含义（真实情况）。

物理功能也是如此。想象一下尝试同时清洁用具和烹饪食物。它们都属于物理功能，它们之间的切换浪费大量时间。从洗碗转为烹饪时，要清洁双手，擦拭双手，清洁水滴，确保肥皂水不会溅到熟食附近等，这会花费一些时间。

多年以来，我已经了解到上下文切换的实际成本，并且它是巨大的。而且，我看到它一直在被低估，即使是高层领导也是如此。

解决上下文切换成本的有效方法之一是遵循批处理的明智建议。从策略上讲，按功能批处理任务。我个人广泛使用它，并已采取了几个步骤。

我将任务放在一个函数中，然后将它们进一步细分为较小的函数。例如，

现在，编写代码和查看代码是同一认知功能中的两个独立功能。甚至为两个单独的代码库编写/查看代码也是两个单独的子功能。

分组/回复所有电子邮件是电子邮件功能。甚至可以进一步分为电子邮件分类功能和响应功能。 （Andreas Klinger撰写的有关如何更有效地使用Gmail的最佳文章）

分批处理极大地提高了我的生产率，我什至无法计算出每天减少的压力。但是为什么批处理有效？

如果我们查看批处理背后的首要原则，我们可以确定批处理会缩小任务的范围并使其具有针对性。每个任务都需要识别，理解然后执行。批处理将所有任务分成特定的存储桶。节省了从一个存储桶跳到另一个存储桶的上下文切换成本。

最好的比喻是将叉子，刀子和汤匙放在抽屉里时对其进行分类。我们可以将所有银器放在一起。但是，每当我们需要汤匙时，要在那堆汤匙中找到汤匙就需要时间。任务从获取勺子（执行）到查找勺子（标识）。这是我们要避免的费用。

如果我们将银器分类并分批放入抽屉中，则可以节省寻找每件商品的成本。通过将分拣银器和其他器具（从洗碗机中出来）进行组合，可以进一步优化此效果。

具有认知功能的任务也是如此。想象一下，在将PR进行批处理，修复给定回购中的错误，在给定的一天参加会议，编写同行评审，回复电子邮件，闲置响应等之后节省了时间。

现在您可能会质疑批处理是否也有效并且需要时间。真的为所有任务而烦恼吗？

我的答案是总是批处理。根据任务的大小，批处理可能花费与完成任务相同的时间。而且在某些情况下，批处理可能比实际工作花费更多的时间。但是批处理也是一项需要开发的技能。

练习较小的任务将使您对较大的任务更有效率。在高级级别，批处理的成本和影响真正可见。进行低风险，低影响的工作有助于避免代价高昂的错误。并允许您为自己的子功能部门提出一个个人级别。精通批处理后，如果您仍然愿意，可以决定跳过它以执行较小的任务。

如果您喜欢这篇文章，请与您的同事分享，并考虑注册以获得更多此类内容。