我在寫本文時狀態並不好:缺少睡眠、忙忙碌碌、不知所措、還總被打斷思緒。我試盡了辦法:使用番茄工作法、在咖啡店工作、戴耳機、只在深夜無人打擾時工作等等。但是打岔的事,總是用不了多久就會攻破我的防護罩。
和你一樣,我是一個“工作總被打斷的程式設計師”。實際上我們對於打斷這件事以及恢復注意力方法的理解,和順勢療法以及放血水蛭相差不遠。但是有什麼證據?又該怎麼做呢?
打斷的代價
我每隔幾個月就能看到另一位程式設計師被要求在工作時間不準使用耳機,或是總被會議打斷以至根本無法工作,他對這些要求頗有些抵抗情緒。我擔心隨著年齡的增加,我們處理這些腦力工作和干擾的能力會有所衰退。
研究過辦公環境下打斷成本的調查員推測,被打斷的工作相比沒有干擾的工作要花費兩倍的時間完成,並且出錯量也是兩倍。他們還發現,人們不得不在碎片化的狀態下工作,因為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通常只包含檔名,急需關聯性。導航文件標籤的預設配置尤其簡樸,通常只顯示文件的名稱,經過優化,可以增強關聯記憶的回想。
情景記憶
情景記憶是對過去事件的回憶。軟體開發者不斷地學習新的技巧。保持和使用這類學到的知識需要程式設計師能夠從情景記憶中回想起那些學習經歷。
程式設計師回憶情景記憶時,回想其必要細節或關鍵事件的能力受到限制,所以一般不會成功。例如,可能會忘記程式設計任務做出的修改,或記不住為實現部分任務而借鑑的部落格等之類的細節。
敘事編碼是一款情景記憶的輔助工具,可以幫助程式設計師回憶上下文細節和編碼歷史。它支援不同型別的敘事;比如,高度還原事件的 review 模式和給別人釋出編碼任務的 share 模式。
獲得敘事編碼的更多資訊,檢視此篇通過敘事編碼半自動分享、釋出的 部落格 。(注意本文完成時,部落格還未更新。)
概念記憶
概念記憶是感知和抽象的一種連續。大腦是如何記得錘子之類的物體和“工具”等概念的?它首先會學習所遇刺激的基本特點,比如錘子的木質紋理和金屬弧,之後將這些特點組織成為更高階的抽象。
程式設計師在職業生涯中應該保持專業技能。但是成為專家的路並不好走:對初學者來說,這可能需要 10 年。此外,對於那些嘗試成為新領域專家的專家來說,就像桌面開發者轉為web開發者,很多概念需要先放在一邊,而去學習新的知識。
研究專家和菜鳥間的不同發現,表現不同是因為大腦活動的不同。與菜鳥相比,專家不僅需要更少的大腦活動,而且使用的大腦部位也不同:專家使用概念記憶而菜鳥使用專注記憶。也就是說專家能夠利用概念記憶中的抽象,而菜鳥只知道專注記憶中的原始表現。
Sketchlet (alpha)是一款為幫助程式設計師形成和掌握概念而設計的軟體工具,通過支援抽象和檢查需更新的概念實現目的。可在 sketchlet.sourceforge.net 上進行體驗。
參考文獻
全部參考文獻列表請看 原文 。
- A diary study of task switching and interruptions (Czerwinski)
- No task left behind?: examining the nature of fragmented work (Mark)
- Resumption strategies for interrupted programming tasks (Parnin, Rugaber)
- Subvocalization – Toward Hearing the Inner Thoughts of Developers (Parnin)
- Task-evoked pupillary response to mental workload in HCI (Iqbal)
打賞支援我翻譯更多好文章,謝謝!
打賞譯者
打賞支援我翻譯更多好文章,謝謝!
任選一種支付方式