刚刚结束 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 大神在剑桥的分布式课程。

我会继续在掘金发文章，包括自己的一些成长感悟，学习的笔记。感谢掘金这个平台。希望大家都能变得更好，成长的更快！