我的一点学习节奏

这篇不讲技术，记录一些关于「怎么学」的体会。写下来主要是给自己看的——过一段时间回头看，能知道当时的想法有没有被验证。

从做东西开始，而不是从看完书开始

我试过按目录把一本技术书从头读到尾，结果是读到第四章就开始走神，读完也说不清学到了什么。

后来换了顺序：先定一个想做出来的东西，遇到不会的再去查。

比如想搞明白数据库事务隔离级别，与其背「读未提交 / 读已提交 / 可重复读 / 串行化」的定义，不如写两个终端手工构造一次并发冲突——开两个会话，一个 BEGIN 但不提交，另一个去读同一行，观察它到底读到了什么。几分钟就能把「可重复读在 MySQL 里到底可重复到什么程度」这件事看明白，而且很难忘掉。

项目驱动的好处是问题是你自己的。别人提出的问题，你只是想知道答案；自己撞上的问题，你是必须知道答案。

留证据，别只留结论

有一条我很早就开始坚持的习惯：任何非平凡的结论，都要能拿出可复现的过程。

• 说某个方案更快 → 有 benchmark 代码和输出
• 说某个配置能解决问题 → 有改前改后的对比
• 说某个 API 的行为是这样 → 有最小复现程序

只留结论的话，过几个月你会发现自己不记得为什么这么判断了。更糟的是，结论可能在当时就是错的，只是恰好没暴露——而没有证据，你没法回溯是哪一步推错了。

留证据还有个副作用：写下来的时候经常发现自己其实没想清楚。脑子里觉得顺理成章的推导，落到文字上会出现断层，那个断层就是理解的缺口。

定期收敛

我的注意力比较容易散。经常是研究 A 的时候看到 B 觉得有意思，转头去看 B，路上又碰到 C。

短期看这是好事——接触面广。但长期下来有个明显的问题：积累了很多「知道」，但没有几样是「能讲清楚」的。

后来给自己定了个规矩：同一时间允许有多个进行中的话题，但每隔一段时间要挑一个收尾，收尾的标准是能输出一篇笔记或者一个能跑的项目。

广度和深度不是二选一，但需要有个机制保证两者都在发生。否则容易滑向只做广度的那一边，而那一侧的边际收益下降得很快。

关于笔记

我的笔记分两类，混在一起会很难用：

一类是输出型的，就是你现在看到的这种。结构完整、给外人看也说得通，写的时候会反复推敲逻辑。

另一类是原始记录型的，随手记命令、报错、片段。不求通顺，只求当时的信息不丢。

两类笔记服务于完全不同的目的。输出型笔记用来确认「我确实懂了」，原始记录用来在下次遇到同样问题时省时间。把原始记录直接当输出用，会得到一堆自己后来都看不懂的碎片；把输出型笔记当草稿用，会因为追求通顺而写不下去。

卡住的时候

卡住是很正常的，而且往往卡住的地方在事后看都很简单。

我的经验是：卡超过二十分钟就换手段，不要继续用同一种方式死磕。可以：

• 把问题的最小复现写出来（经常写到一半自己就发现了）
• 去看官方文档而不是搜索引擎的结果页
• 去读源码，尤其是那些有详细注释的运行时或框架代码
• 把已经确定的事实列出来，看看缺的是哪一环

最后一条特别有效。卡住往往不是因为信息不够，而是因为把某个猜测当成了事实。把确定的部分和猜测的部分分开写，错误假设会立刻暴露出来。

最后

没有捷径，也没有能让人突然开窍的方法。能做的就是把过程变得可验证一点、可回溯一点，然后别停。