微信搜尋 【大遷世界】, 我會第一時間和你分享前端行業趨勢，學習途徑等等。
本文 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 已收錄，有一線大廠面試完整考點、資料以及我的系列文章。
