程序员工作时被打断了该怎么办?

  编译:伯乐在线/古鲁伊

  我在写本文时状态并不好:缺少睡眠、忙忙碌碌、不知所措、还总被打断思绪。我试尽了办法:使用番茄工作法、在咖啡店工作、戴耳机、只在深夜无人打扰时工作等等。但是打岔的事,总是用不了多久就会攻破我的防护罩。

  和你一样,我是一个“工作总被打断的程序员”。实际上我们对于打断这件事以及恢复注意力方法的理解,和顺势疗法以及放血水蛭相差不远。但是有什么证据?又该怎么做呢?

  打断的代价

  我每隔几个月就能看到另一位程序员被要求在工作时间不准使用耳机,或是总被会议打断以至根本无法工作,他对这些要求颇有些抵抗情绪。我担心随着年龄的增加,我们处理这些脑力工作和干扰的能力会有所衰退。

  研究过办公环境下打断成本的调查员推测,被打断的工作相比没有干扰的工作要花费两倍的时间完成,并且出错量也是两倍。他们还发现,人们不得不在碎片化的状态下工作,因为57% 的工作都会受到干扰(详见 参考文献)。

  对于程序员来说,干扰的影响和现状更不明显;通常被打断后重回工作状态至少要15分钟。采访程序员得出的数字大致相同。然而很多软件开发业界的知名人士已经在权衡:Y Combinator 创始人 Paul Graham 强调了员工日程和管理者日程的不同,37signals 创始人 Jason Fried 说,办公室就是要被打扰的地方。

  研究程序员的干扰

  基于86位程序员使用 Eclipse 和 Visual Studio 记录的 10,000 个程序会话,并且调查了 414 名程序员后我们发现:

  • 工作被打断的程序员恢复工作后要 10-15 分钟才会开始敲代码。

  • 程序员在编写一个方法时被打断,不到一分钟就会恢复工作状态,所用时间仅为上述时间的十分之一。

  • 程序员一天大概只有两个小时的连续时间不受干扰。

  我们也了解了一些程序员应对干扰的方法:

  • 多数情况下,程序员会在重新编码前导航到几个不同位置以重新建立上下文。

  • 有意插入编译错误作为“路障”提示。

  • source diff 被视为是恢复工作状态的最后一个方法,因为 review 起来很麻烦。

  打断程序员最糟糕的时间

  调查显示打扰一个人最糟糕的时间是他们记忆负载最重的时候。对记忆负载使用神经关联(比如测量瞳孔直径),研究表明在负载高峰期被打断,分散最严重(如 图1)

  在我们的实验中,为了给编程任务期间的记忆负载定级,我们研究了默读方式(如 图2)。人们执行复杂任务时,可以监测到默读方式(舌头、嘴唇或声带的电信号)。这个现象引起了研究者的兴趣,有些甚至将默读信号比作思想管道。近日,研究者已经可以将这些信号解码为文字了。

  如果一个被打断的人可以暂停工作状态或是恰好处于“good breakpoint”,那么被打断的影响就会减小。但是程序员从高记忆状态转换到低记忆状态至少需要 7 分钟。一个实验评价出了程序员最不想被打扰的状态,并发现以下状态最成问题:

  • 编码中,特别是多处的并行编码

  • 导航和搜索时

  • 理解代码的数据流和控制流时

  • IDE窗口离焦时

  创造记忆友好的环境

  我们基本上是无法消除干扰的。(某些情况下,干扰也是有益的;被打断的任务中有 40% 没有继续下去,这可能是因为我们意识到这些任务并没有那么重要,或是干扰让我们有机会重新审视问题。)但是我们可以降低因打断而造成的记忆中断的影响。下一节会介绍几种编程时被中断或高负荷的记忆类型,并讨论支持它们的辅助工具概念。

  前瞻记忆

  前瞻记忆会在某些特定环境下提示下一步的动作——例如,提醒你在下班路上买牛奶。

  各种各样的研究已经阐述了程序员是如何尝试应对前瞻记忆中断的。例如,他们经常在代码中保留 TODO 注释。这种方法的缺点是没什么动力去看这些提示。为了强制性促进前瞻性,程序员可能会故意留下编译错误来确保记得继续某项工作。但是,引入编译错误又会产生新的问题,因为无法在同一代码库上切换到另一个任务。最终,程序员和其他上班族一样,选择用便利贴或是邮件提醒自己。

  “智能提示”可以在特定情况下触发,比如当同事 check in 代码时,或是接近提示时(如 图3),它基本可以看做是代码界的便利贴。

  专注记忆

  专注记忆可以有意识的保持注意力。程序员跨代码库做相似修改时可能会产生专注记忆——比如,如果需要为了移动组件位置重构代码,或是为了使用新版本的 API 更新代码,这时程序员需要小心系统地编辑所有需要更改的地方。即使是一个小的改动也可能会造成许多问题,所以这需要程序员监测代码中许多位置的状态。更糟糕的是被打断后,专注记忆中的监测状态很快消失不见,之前查看和修改过的许多地方都需要重来。

  接触点(如 图4)可以让程序员监测多个位置的代码状态。研究发现使用工具重构有缺陷,其中之一就是缺少跟踪多处代码的能力。因此,程序员抛弃了重构工具而依靠重构时引入的编译错误。可是使用编译错误来跟踪变化不是常规方法,并且依然会产生错误。接触点从程序员使用编译错误的方式获得启发。通过提取所有最近访问、编辑、查找过的代码,接触点可以自动恢复。

  联想记忆

  联想记忆维持了一系列同时产生刺激的表象间的潜意识关联。

  程序员导航到不熟悉的代码时常会感到迷惑。当必须回想所看代码的位置信息或是接下来要看什么时,联想记忆会中断,这就是造成迷惑的原因。研究者相信界面元素中缺少丰富、稳定的环境提示,比如文档标签,会阻碍开发者回忆联想记忆。

  刺激中多种形式的存在可以增强塑造联想记忆的能力。从这个意义上讲,形式指一种由大脑的特定区域处理的特定知觉,比如听觉或视觉通路。不同形式和相应的刺激包括:视觉(错误条、高亮代码)、词汇(文件名)、空间(滚动条或标签的位置)、操作(文件的编辑/搜索/调试步骤)和结构(层级文件的逻辑位置)。

  当同一刺激中存在多种形式时,更多的通路被激活,因此增加了形成联想记忆的机会。相反,仅有一种形式的单一刺激不易形成联想记忆。

  联想关联通过程序元素中多种形式信息帮助程序员;观察程序员可以发现,他们导航时经常依赖环境提示间的联系,比如 tab 和 scrollbar,来保持上下文。但是,这些提示还不够:导航行为经常会扰乱提示的状态,界面元素不足,比如tab通常只包含文件名,急需关联性。导航文档标签的默认配置尤其简朴,通常只显示文档的名称,经过优化,可以增强关联记忆的回想。

两个应用了不同形式提示的标签:如error lines(视觉)和edit icons(操作)。

  情景记忆

  情景记忆是对过去事件的回忆。软件开发者不断地学习新的技巧。保持和使用这类学到的知识需要程序员能够从情景记忆中回想起那些学习经历。

  程序员回忆情景记忆时,回想其必要细节或关键事件的能力受到限制,所以一般不会成功。例如,可能会忘记编程任务做出的修改,或记不住为实现部分任务而借鉴的博客等之类的细节。

  叙事编码是一款情景记忆的辅助工具,可以帮助程序员回忆上下文细节和编码历史。它支持不同类型的叙事;比如,高度还原事件的 review 模式和给别人发布编码任务的 share 模式。

编码时间轴可以帮助你和你的同事记得各自是如何工作以及使用的资源。

  获得叙事编码的更多信息,查看此篇通过叙事编码半自动分享、发布的 博客 。(注意本文完成时,博客还未更新。)

  概念记忆

  概念记忆是感知和抽象的一种连续。大脑是如何记得锤子之类的物体和“工具”等概念的?它首先会学习所遇刺激的基本特点,比如锤子的木质纹理和金属弧,之后将这些特点组织成为更高级的抽象。

  程序员在职业生涯中应该保持专业技能。但是成为专家的路并不好走:对初学者来说,这可能需要 10 年。此外,对于那些尝试成为新领域专家的专家来说,就像桌面开发者转为web开发者,很多概念需要先放在一边,而去学习新的知识。

  研究专家和菜鸟间的不同发现,表现不同是因为大脑活动的不同。与菜鸟相比,专家不仅需要更少的大脑活动,而且使用的大脑部位也不同:专家使用概念记忆而菜鸟使用专注记忆。也就是说专家能够利用概念记忆中的抽象,而菜鸟只知道专注记忆中的原始表现。

  Sketchlet (alpha)是一款为帮助程序员形成和掌握概念而设计的软件工具,通过支持抽象和检查需更新的概念实现目的。可在 sketchlet.sourceforge.net 上进行体验。

通过将编程环境展开成片,“Code Pad”上的sketchlets可以提供额外的精神空间来构建和记忆代码概念。

声明:本文由入驻搜狐公众平台的作者撰写,除搜狐官方账号外,观点仅代表作者本人,不代表搜狐立场。
推荐阅读