原創 梧忌 淘系技術 6月15日
“心流”是人在做一件事情時投入到忘我的一種精神狀态，常見于運動員、藝術家和科研人員身上。“心流”如何影響工作？我們可否解決“心流”帶來的相關問題？
我在學生時代是個狂熱的 NBA 球迷，家裡總是堆滿了籃球報，工作後我對籃球熱情開始退去，直到斯蒂芬·庫裡的出現。
斯蒂芬·庫裡改變了籃球比賽的打法。他身高1.91米，在 NBA 中屬于矮個子球員，但隻要他進入比賽狀态，他幾乎可以毫不費力地在對方半場上的任何位置命中三分球。他打球的方式讓人賞心悅目。
他不僅帶領金州勇士隊奪得了 NBA 的總冠軍，而且還颠覆了所有 NBA 球員和球隊的比賽風格 —— 他證明了不需要成為中鋒的那樣的大個子也能赢得比賽。斯蒂芬·庫裡之後，越來越多的球員和球隊開始練習和多投三分球。
每個運動員都可以通過刻意地訓練來找到自己的比賽狀态，然後主宰比賽。
我們可以從斯蒂芬·庫裡身上學習到什麼？“比賽狀态”到底指的又是什麼？
高效編碼的秘訣：“心流”
20 世紀 70 年代，積極心理學領域的權威 Mihaly Csikszentmihalyi 定義了一種名為“心流”的狀态，這在運動員、藝術家和科研人員身上可以經常看到。
Csikszentmihalyi 研究了是什麼讓人們感到快樂，他發現，人們在“心流”狀态下最快樂。
大多數人都有過這樣的經曆：忽然擡起頭，發現時間已經過去了很久，自己已經完成了一系列的工作。那種輕松富有成效的時間流逝和揮之不去的成就感，令人愉悅。
“心流”是高效編碼的秘訣。但是要達到“心流”的狀态并不容易，來看看阻礙我們進入“心流”狀态的幾個問題。
▐ 外界的幹擾
| 圖檔來源：截取自《社交網絡》電影
這是一個重大而又經常出現的情況：突然的外界幹擾，會破壞我在編碼時的思緒，打亂我正在大腦中加載的邏輯。例如，我會被釘釘或其他應用程式的消息幹擾，又或者是到身邊來問問題的同僚幹擾。相信每個開發者都曾經遇到過這樣的場景：
| 圖檔來源：THIS IS WHY YOU SHOULDN'T INTERRUPT A PROGRAMMER
會議是影響“心流”的另一個明顯的問題，但可能大家沒有注意到的是它們在會議時間之外的其他影響，如圖所示：
| 圖檔來源："Anyone who ever schedules meetings with developers, please burn this image into your brain, thanks"
通常在開會之前，我知道很快就要進入到會議當中，是以會中斷掉編碼，然後準備會議的頭腦狀态。會議結束後，還需要時間來消化内容、讓自己恢複到正常的腦力狀态。
是以，Facebook 的 “周三不開會” 倡議受到工程師們的普遍歡迎，大家都認為這将有助于提升開發人員的生産力。
但是我們是隻關心一周中一天的編碼時間嗎？有沒有想過，在标準工作時間，會議頻繁的時候，我們真正輸出了多少代碼？
▐ 人的思維慣性
技術正在飛速發展，總有很多的東西需要研究和學習。我經常思考如何平衡花在學習和編碼上的時間。
保持專注并不容易，需要克服種種的思維慣性。我經常陷入到這種拖延的慣性當中：看會兒某乎再開始吧，還可以順便檢查一下郵件......午飯後再開始寫吧，畢竟還有半小時就到午飯時間了……
有時候“心流”的敵人就是自己。
需要意志力和紀律才能将全部工作分解為小的、可操作的工作單元，然後才可以開始編碼。
解決這些問題的對策
▐ 設定編碼時間
了解“心流”之後，關鍵是找到自己的「心流時刻」。可以借助在編輯器上的行為來捕獲和分析程式設計活動的軌迹得出來。
如果去跟蹤我們的編碼活動，例如鍵盤輸入、添加的字元和删除的字元，然後就可以在幾天或幾周後得出一定的規律。有了足夠的資料，就可以建構一個熱圖來檢視開發者通常在何時高頻輸出。這個可能就是你的「編碼心流時刻」。
| 圖上的藍色點顔色越深，代表在此時刻早鍵盤的輸入越多。
然後，你就可以開始通過工作月曆來設定自己的編碼時間。開會、寫代碼、閱讀，它們需要的狀态和腦力是完全不同的，可以自己的情況來計劃哪個時間段來執行這些任務。
将這些時間規劃設定到你的工作軟體（釘釘）上，讓它們在這些時間段進入到免打擾模式，不再有應用程式的消息提示視窗，同時它還在提醒你的同僚避免在這些時間段約你開會等等。
▐ 持續完善文檔
會議往往是異步溝通無效的展現。另外，根據 Stack Overflow 的調研報告，幾乎一半的開發者表示他們在遇到問題時會打電話給同僚。為了減少會議和答疑，一個建議是持續地更新和完善文檔：更好的文檔可以幫助你更快地回答同僚的問題，并減少被打擾的可能性。
你知道自己在寫文檔上的投入如何嗎？或許看看你在編輯器上對文本檔案的編輯時間投入可以得出一些結論。
▐ 高效會議并回顧
更有效的會議可以避免更多的會議。
明确會議主持，制定會議議程，做好會議記錄，産出會議結論 —— 這些都是高效會議的一些措施。
另外，有必要考慮一下你是否真的需要參加這個會議。斯坦福大學的研究表明，當會議的參與者隻有 5 ~ 8 人時，效率最高。還有 Atlassian 的一篇文章說，近 40% 的員工會在會議期間昏昏欲睡。。。
最後，結合工作月曆和編碼熱圖，可以建構會議與編碼時間的關系圖。可以看看你到底是花了更多時間在開會還是在編碼？會議時間的增加是怎麼影響編碼時間的？
▐ 克服思維慣性
每個人都需要一些動力來克服行為和思維慣性。可以問一下你自己：每天在八卦群上閑聊的花費了多少時間？是不是經常走神拿起手機刷朋友圈、短視訊？如果可以記錄并繪制你的程式設計活動圖，那麼：
- 你可以很快地看到你最近一天或一周的編碼投入是否高于或低于自己的平均值。
- 你可以看到你每個時刻的編碼輸出情況，想想那些資料斷層是因為你在思考還是走神了？
與自己對比來找到最好的自己，關注你的編碼資料和設定目标可以提高自己的紀律性和産出。
Time Master
這就是為什麼 AppWorks 打造 Time Master 的原因。軟體正在改變世界，數字化正在影響着我們生活的方方面面，關于我們如何開發軟體的資料也很重要。
Time Master 記錄和可視化開發者的程式設計資料，幫助開發者發現并找到“心流”狀态，實作高效編碼。
這一切，完全是自動的。你隻需要在你的 VS Code 上安裝該插件即可：
然後你在編輯器端，就可以看到你的程式設計活動統計資料：
在阿裡内網的線上站點，可以看到程式設計活動的趨勢和分析：
| 僅為功能示意，部分圖表仍在設計或開發中。
除了幫助開發者進入“心流”狀态，Time Master 還有更多的想象空間和其他意義。
▐ 越早編碼越好？
Joel Spolsky，Trello 和 Stack Overflow 的創始人在他的部落格中說道：
Sometimes I just can't get anything done.Sure, I come into the office, putter around, check my email every ten seconds, read the web, even do a few brainless tasks like paying the American Express bill. But getting back into the flow of writing code just doesn't happen.
Spolsky 分享了一個簡單的見解：“「立刻開始做」也許是提升生産力的關鍵”。
資料可以為生産力的提升提供強大的推動力。為了克服早上的慣性，我們可以做的，最簡單的事情之一就是跟蹤我們每天開始編碼的時間：
| Time Master 可以從開發者的編輯器中自動地跟蹤編碼開始時間。
- 為什麼要跟蹤編碼開始時間？
開始編碼的時間越早，當天編碼的時間可能就越多；）越晚開始，檢視電子郵件或社交媒體的次數越多，需要克服的慣性就越大。
你上班的第一件事是編碼，還是浪費在檢視社交媒體和電子郵件上？一個建議是：應該将工作的第一個小時花在高價值的事情上。
- Code First
Code First 是開發人員或團隊用來提高生産力的一種工作指導原則。
- Code First 意味着要快速原型制作以了解其工作模式而不是進行寬泛的研究和計劃。
- Code First 意味着盡可能地進行編碼以進入”心流時刻“，意味着将編碼時間置于會議和其他時間之前，優先滿足對編碼時間的要求。
- Code First 與代碼品質并不沖突，可以與對單元測試和嚴格的代碼審查相結合。
一旦可以檢視多天和一周中特定某天的編碼開始時間，開發者就可以設定目标以提高其一緻性并踐行 Code First。
▐ 代碼重構率
開發者編寫代碼，然後重構一些代碼，然後再重構一些代碼。
就好像我寫的這篇文章，我會先寫一個版本，然後再次閱讀，優化一些語句，添加或删除一些段落；最後我再檢查一遍，修正一些錯别字。最終我将産出一個經過稽核的、品質更高的版本。
代碼重構的情況與之類似。首先必須了解：代碼重構是很正常的，或者說在研發過程中是健康的，這裡講的“重構”并不是推翻過去的一切。
問題是我們可以從跟蹤代碼重構中學到什麼嗎？—— 分析代碼重構的過程或許可以幫助我們更好地進行編碼。
- 代碼重構率的定義
代碼重構率是指在編寫的代碼總量（總代碼）中被重寫的代碼量的占有率。
總代碼可以分為三類：添加的字元、删除的字元和粘貼的字元。總代碼可以通過按鍵和字元，資料的最小原子機關來計算，也可以使用代碼行數來計算，這因編碼風格、文本編輯器而異。
- 代碼重構的原因
代碼重構有被動的原因，例如：市場發生了變化，導緻産品需要更新；産品經理更新了需求；我們發現架構或設計中存在嚴重缺陷；又或者我們在代碼中發現需要修複的錯誤。
當然也有主動的原因。優秀的開發者通常會快速産出原型，以了解正在創作的軟體的知識範疇以便學習，這也是踐行 Code First 工作原則的一種展現。
在開源技術被廣泛應用的今天，豐富的示例可以幫助開發者快速開始某項編碼工作，開發者經常需要內建和粘貼代碼，然後在內建的過程中删除一些代碼 —— 這也是代碼重構的一種原因。
此外當我們改進代碼時，例如消除備援、提升性能或提高可讀性，也會進行代碼重構。
總結一下：
- 好的代碼重構原因：學習、內建、優化；
- 差的代碼重構原因：市場變化、需求變化、架構或設計問題、代碼缺陷；
代碼重構的成本随着時間的推移而變化。在修複缺陷時，随着軟體開發生命周期的進展，成本會急劇上升。在生産階段修複錯誤的成本可能比在設計中修複它的成本高 100 倍。
| 圖檔來源：IBM 系統科學研究所
最早且修複成本最低的代碼重構分析是在送出到 Git 倉庫之前，即在 IDE 中進行的代碼重構。這就是為什麼我們需要追蹤程式設計活動的原因之一。
- 在代碼重構中學習
檢視代碼重構相關的資料可以挖掘程式或産品的大量資訊。例如，軟體開發生命周期後期的高代碼重構率可能表明存在品質和生産力問題。此外，如果将代碼庫中所有檔案的代碼變動可視化，還可以了解開發工作都花在了哪裡。
了解自己代碼重構率，與團隊成員對比，可以讓你看看自己的工作方式是否有改進的空間。
▐ 工作與生活的平衡
工作與生活的平衡一種健康的身心狀态，兩者的平衡可能跟我們在其中投入的時間有關。改善工作與生活的平衡可以提高幸福感和生産力，同時防止過度疲勞。
Time Master 采集了我們的編碼資料，是以可以了解到我們在工作時間和工作時間之外的編碼時間，幫助我們了解工作與生活的平衡情況。将編碼熱圖和工作月曆結合，還可以檢視會議時間和變是如何影響編碼時間的，進而合理安排你的日程來改善工作與生活的平衡。
例如可以通過幾個次元來看工作生活的平衡：在工作時間段内進行的編碼時間的百分比、工作時間段内的編碼時間變化趨勢、又或者跟自己過往的資料或者同僚的資料進行對比。上面的示例圖表是按照按星期幾來顯示的，跟同期資料對比會更有意義，還可以深入了解開發者在周末編碼投入。