剛剛結束 4 月在掘金髮文的旅程，有很多感悟，在五一假期裡記錄下來。

背景

在掘金註冊賬號其實是 18年的事了，當時剛剛拿到 master 學位，從匹茲堡飛回北京入職。看了看國內的技術社群，對掘金整體的設計很有好感，就下載了 App。

後來年輕的自己經歷各種業務開發上的毒打，時間被極度壓縮，能按時交付高速迭代的需求已經不易，除非業務需要，其他時間很少學習。這種節奏雖然帶來了不錯的績效，但整個人的狀態很不理想。

忙不等於成長，不主動思考和突破舒適區，乾的再多，也只不過是熟練而已。

這個階段的自己十分透支，平常也只是偶爾才會看看掘金，從來也沒想過自己來發文。坦率地講，真正技術側的積累並不多，知識偏向於碎片化，一點都不繫統。

後來轉向了 B 端的業務後，整體倒排少了很多，節奏鬆弛了下來。回望自己這幾年的研發生涯，常常感到自己欠缺的太多，需要好好學習，補上短板。於是開始參與開源社群，儘可能地瞭解優秀開源框架的設計，看原始碼，提 PR，嘗試提升自己。

就是在這樣的背景下，我真正開始用起來掘金，參加【日新計劃 · 4 月更文挑戰】。

體會

作為一個從來沒在公開平臺上發技術文章的研發，一開始我其實並不打算寫太多，因為開始注意到活動就已經是4月8號了，即便寫滿剩下的日子，也只能達到 21 天的標準，而且自己的儲備其實不太多。真正要寫文章其實還是有不小壓力的。

但 21 天其實也是一個好習慣養成的時間，並且也有對應的獎勵，我覺得自己在過去這些年浪費了很多時間，為什麼不嘗試一下呢？

對自己的要求： - 每天一篇技術文章，即刻開始，寫到月底； - 主題必須是自己此前不太熟，至少不在舒適區內，需要自己去學習，查資料，花時間消化的內容； - 不在意活動本身的字數或程式碼文字要求，輸出的內容一定要對自己很有幫助，有意義，不去 match minimum requirement； - 不提前準備，不要為了完成活動指標，去屯好文章，只是每天發。一定要每天現想，現寫； - 可以參考材料，但是不能整段大量拷貝，這樣是自欺欺人，哪怕自己說的沒有別人好，也要寫自己的理解； - 寫文章的終極目的，是【輸出倒逼輸入】，參加活動是順手的，所以一定要保證讓自己受益。

很慶幸，自己最後還是完成了這個 21 天的旅程，在 4月8號前，我從來沒想過我的4月竟然會輸出20+的技術文章。從 gorm, 測試，依賴注入，協程池，到 kitex, 錯誤處理，反射。每一篇都是自己曾經很希望搞清楚，但由於種種原因，一直沒能落地的主題。

首次嘗試發文，行文的邏輯，內容的質量其實都很一般，很感謝文章讀者們的包容。不過確實達到了我對自己的要求，實現了通過【輸出】來強迫自己抽時間去【輸入】，去思考，去實踐。而不是似是而非地矇混過關。

【4 月更文挑戰】活動已經結束，我不知道具體多少篇最後會被稽核為有效，會有多少人看到，但這不重要，我很感謝，這個願意拼一把的自己。

這 22 天其實自己經常被折騰的死去活來，非常崩潰。每天一睜眼就要想【今天到底要寫啥】，話題太大怕一天的時間內hold不住，太小了是對自己的不負責任。每天寫完釋出的時候，都感覺是完成了一件大事，心裡非常舒服。不僅僅是因為活動繼續，而是我真的通過【輸出】，學到了很多東西，明確了一些自己一直疑惑，但因為拖延而沒去了解的問題。

誠然，自己也確實因為要保持每天一篇，其實耽誤了一些工作，我覺得如果再來一次，時間管理上自己需要做的更好。

有一些比較大的話題確實很難 hold 住，坦率的說，雖然發出來了，但是我對其中好幾篇並不滿意，整體還是沒有把問題根源把握住，沒有講透。這裡也對所有文章的讀者說聲抱歉。也是自己最大的遺憾。

方法論

這是我最想總結的部分。通過這一個月在掘金寫文章，自己對於如何學習，作為一個工程師如何成長有了很多不一樣的體會。希望能提煉出來，作為自省。

這段時間感觸最深刻的，還是那個經典的理論：【輸出倒逼輸入】。

如果不需要【輸出】，你很難驗證你的【輸入】是否有效。很多時候我們會「划過去」，我聽了，我看了，我大致理解了，就以為懂了，其實差的還非常遠。

碼農屆經常說一句話：Talk is cheap, show me the code。說的天花亂墜，給不出例子，沒法落地，就全是紙老虎。

其實是一個道理，誤把【輸入】當成【學習了】是一個經典的 illusion。我傾向於把學習從輸入到結束，劃分為下面幾個等級：

• 級別一：輸入了，完全沒懂，左邊進右邊出；
• 級別二：輸入了，似乎懂了一些，感覺有點吃力；
• 級別三：輸入了，大部分懂了，留下了印象；
• 級別四：輸入了，懂了，關鍵點記下來了；
• 級別五：輸入了，記住了，能系統地梳理知識點，能給別人講出來 What 和 How；
• 級別六：不僅能給別人講，能落地程式碼實踐，也能自己獨立去推理，探索到 Why 的層面。

級別四以下的，坦率的講，跟無效學習意義不大。很難去【內化】什麼東西。

大部分時候學習都會停留在級別四，覺得自己懂了，大體也知道有一些點，但是隨便問兩下就懵了。但是礙於時間關係，如果你能把自己大部分的學習控制到至少達到【級別四】，也已經不錯了。

真正的學習，是級別五和六。尤其是作為碼農，【大概知道】是沒有意義的，無法轉化為深刻的理解，你就不太敢上生產環境。程式碼沒 ready，概念無法脫口而出，這不叫真正的學會了。

針對一個知識點，應該自己有一個評估，掌握的程度到哪裡：

• What：是什麼，這個定位是要解決什麼問題，提供什麼能力，簡單來說一個詞：會用。
• How：怎麼實現的？是什麼原理？在哪些場景下效果最好？
• Why：為什麼這樣設計？有沒有別的方案，是不是可以改進？

我們以 sync.Mutex 為例對映一下：

• What：Mutex 提供了什麼能力，應該怎麼用，有什麼用法需要注意的地方，他的定位是什麼場景；
• How：Lock 和 UnLock 的原理是什麼？自旋，飢餓模式，有什麼條件？訊號量是幹啥的？要看到原始碼，理解實現原理；
• Why：為什麼要有【自旋】？訊號量設計的好處在哪兒？飢餓模式是啥時候加進來的？如果不加會有什麼問題？

懂了 What，就能用起來了。我們也不可能所有依賴的開源庫都一個個看實現，熟練，明確地掌握 What 對於大部分場景是夠的。如果連 What 都只是似懂非懂，無法自信地說出來的話，這個知識點只能認為是完全沒掌握。

寫程式碼也好，寫文章也好，亦或是錄影片給別人講，這都是【輸出】。對於經典的材料我們應該力圖去理解，隻字不差地閱讀，核心知識點是需要花時間記憶的，要達到脫口而出。What 和 How 理解之後，再去延伸 Why 的部分。這樣效率才會高。

知識，要麼不學，要麼就鄭重的學，如果一段時間【學習】結束了，一定要問問自己，內化了幾成，能脫口而出關鍵點麼？如果你剛學完，都還不能脫口而出，那很難要求自己在未來某天真正遇到問題了，還能想起來。

這段時間領悟的一些理念，統一列一下，作為自己懈怠時候的提醒： - 記憶很重要

似是而非地理解從長期來看沒有任何意義，核心概念，基礎內容必須記住，能脫口而出，能圖形化表達。

• 輸出才算學習

  學習了知識，條件可以的情況下，儘可能地用程式碼表達，嘗試 demo。至少要輸出一篇讀書筆記，總結。這樣能輔助自己不划水； - 優先安排學習任務

  既然認同學習是重要的，就不要把它排在最後，否則你永遠抽不出時間。把你一定要完成的工作，壓力大的活往後排，這樣你會逼自己一把，因為必須要完成，最後一定會去做。你會很崩潰，也許睡不了多長時間，但你慢慢地就會調整，知道如何更有效率地去學習，去完成工作； - 專注於經典

  連續的學習時間，一定要留給經典的資料，比如 CSAPP, DDIA等。學習的資料有很多，不要迷失方向。認認真真理解經典資料，從 What 到 How 再到 Why 完整理解並輸出，遠比看普通的專欄要好。當然，經典由於文字表述等原因，有時候不太通俗，或者一些細節沒有涵蓋。這個時候當然要去找資料，看其他來源的輸入去理解。重點在於，你要明白自己的主線，而不是隨便在網上找了個書/專欄就開始看，以為看完了就徹底懂了。開發者的時間很寶貴，要能區別出來學習的主次。

• 填充自己的知識框架

  不繫統的學習就像狗熊掰棒子，學了，沒地方存，知識在無意間就被自己的大腦扔掉了。只剩下【印象】，既不繫統也不具體，真正需要的時候你不敢去信任。同一主題，你會發現碎片化的知識哪裡都是，似乎永遠學不完。要主動去建立自己的知識體系，當看一篇文章的時候，本質是往這個框架裡去填充，這個填充非常重要。意味著，一個新的知識點來的時候，你的大腦裡是有一塊地方，有一個位置留下來的，這樣你就能去檢視，ok，這個點是新的，那麼我直接存進去就ok（你自己是知道他在哪兒的，而不是無意識的理解了就算了）。如果此前有一些存貨，那就看和我之前理解的是否一樣，是否有一些獨到的點是可以補充的，這個時候就去 Update 即可。讓知識有址可尋，這個很重要。

後面的計劃

連續更文這一個月其實狀態不錯，但也很疲憊。因為希望發文是至少符合要求的，一篇完整的文章，而不是摘抄筆記，或是隨便翻譯一下就發了。整體標準偏高，希望儘量是自己的東西。這樣負擔比較重。

下來還有很多有意思的課程，書想去閱讀，學習，實踐。比如 DDIA 作者 Martin Kleppmann 大神在劍橋的分散式課程。

我會繼續在掘金髮文章，包括自己的一些成長感悟，學習的筆記。感謝掘金這個平臺。希望大家都能變得更好，成長的更快！