如何用“心流”提升編碼工作效率？

主宰比賽是什麼意思

梧忌 淘系技術

“心流”是人在做一件事情時投入到忘我的一種精神狀態，常見於運動員、藝術家和科研人員身上。

“心流”如何影響工作？我們可否解決“心流”帶來的相關問題？

我在學生時代是個狂熱的 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 採集了我們的編碼資料，因此可以瞭解到我們在工作時間和工作時間之外的編碼時間，幫助我們瞭解工作與生活的平衡情況。將編碼熱圖和工作日曆結合，還可以檢視會議時間和變是如何影響編碼時間的，從而合理安排你的日程來改善工作與生活的平衡。

例如可以通過幾個維度來看工作生活的平衡：在工作時間段內進行的編碼時間的百分比、工作時間段內的編碼時間變化趨勢、又或者跟自己過往的資料或者同事的資料進行對比。上面的示例圖表是按照按星期幾來顯示的，跟同期資料對比會更有意義，還可以深入瞭解開發者在週末編碼投入。