（给
伯乐在线
加星标，看经典文章
）
编译：伯乐在线/古鲁伊
我在写本文时状态并不好：缺少睡眠、忙忙碌碌、不知所措、还总被打断思绪。我试尽了办法：使用番茄工作法、在咖啡店工作、戴耳机、只在深夜无人打扰时工作等等。但是打岔的事，总是用不了多久就会攻破我的防护罩。
和你一样，我是一个“工作总被打断的程序员”。实际上我们对于打断这件事以及恢复注意力方法的理解，和顺势疗法以及放血水蛭相差不远。但是有什么证据？又该怎么做呢？
打断的代价
我每隔几个月就能看到另一位程序员被要求在工作时间不准使用耳机，或是总被会议打断以至根本无法工作，他对这些要求颇有些抵抗情绪。我担心随着年龄的增加，我们处理这些脑力工作和干扰的能力会有所衰退。
研究过办公环境下打断成本的调查员推测，被打断的工作相比没有干扰的工作要花费两倍的时间完成，并且出错量也是两倍。他们还发现，人们不得不在碎片化的状态下工作，因为57% 的工作都会受到干扰（详见 参考文献）。
对于程序员来说，干扰的影响和现状更不明显；通常被打断后重回工作状态至少要15分钟。采访程序员得出的数字大致相同。然而很多软件开发业界的知名人士已经在权衡：Y Combinator 创始人 Paul Graham 强调了员工日程和管理者日程的不同，37signals 创始人 Jason Fried 说，办公室就是要被打扰的地方。
研究程序员的干扰
基于86位程序员使用 Eclipse 和 Visual Studio 记录的 10,000 个程序会话，并且调查了 414 名程序员后我们发现：
我们也了解了一些程序员应对干扰的方法：
打断程序员最糟糕的时间
调查显示打扰一个人最糟糕的时间是他们记忆负载最重的时候。对记忆负载使用神经关联（比如测量瞳孔直径），研究表明在负载高峰期被打断，分散最严重（如 图1）
在我们的实验中，为了给编程任务期间的记忆负载定级，我们研究了默读方式（如 图2）。人们执行复杂任务时，可以监测到默读方式（舌头、嘴唇或声带的电信号）。这个现象引起了研究者的兴趣，有些甚至将默读信号比作思想管道。近日，研究者已经可以将这些信号解码为文字了。
如果一个被打断的人可以暂停工作状态或是恰好处于“good breakpoint”，那么被打断的影响就会减小。但是程序员从高记忆状态转换到低记忆状态至少需要 7 分钟。一个实验评价出了程序员最不想被打扰的状态，并发现以下状态最成问题：
-
编码中，特别是多处的并行编码
-
导航和搜索时
-
理解代码的数据流和控制流时
-
IDE窗口离焦时
创造记忆友好的环境
我们基本上是无法消除干扰的。（某些情况下，干扰也是有益的；被打断的任务中有 40% 没有继续下去，这可能是因为我们意识到这些任务并没有那么重要，或是干扰让我们有机会重新审视问题。）但是我们可以降低因打断而造成的记忆中断的影响。下一节会介绍几种编程时被中断或高负荷的记忆类型，并讨论支持它们的辅助工具概念。
前瞻记忆
前瞻记忆会在某些特定环境下提示下一步的动作——例如，提醒你在下班路上买牛奶。
各种各样的研究已经阐述了程序员是如何尝试应对前瞻记忆中断的。例如，他们经常在代码中保留 TODO 注释。这种方法的缺点是没什么动力去看这些提示。为了强制性促进前瞻性，程序员可能会故意留下编译错误来确保记得继续某项工作。但是，引入编译错误又会产生新的问题，因为无法在同一代码库上切换到另一个任务。最终，程序员和其他上班族一样，选择用便利贴或是邮件提醒自己。
“智能提示”可以在特定情况下触发，比如当同事 check in 代码时，或是接近提示时（如 图3），它基本可以看做是代码界的便利贴。
专注记忆
专注记忆可以有意识的保持注意力。程序员跨代码库做相似修改时可能会产生专注记忆——比如，如果需要为了移动组件位置重构代码，或是为了使用新版本的 API 更新代码，这时程序员需要小心系统地编辑所有需要更改的地方。即使是一个小的改动也可能会造成许多问题，所以这需要程序员监测代码中许多位置的状态。更糟糕的是被打断后，专注记忆中的监测状态很快消失不见，之前查看和修改过的许多地方都需要重来。
