大家好，我是Z哥。

之前写了一篇关于阅读源码到底有多少价值的文章《阅读源码的真正价值》，反响还不错。

在文中我向你阐明了阅读源码5个价值。

1. 面试

2. 在工作中更快地上手新项目

3. 给自己创造用新技术的机会

4. 完善知识体系

5. 学习别人的设计思路

那么今天我就和你来聊聊如何更好地阅读源码，毕竟阅读源码这件事做起来还是有一定难度的，特别是刚起步的时候。

而且有些巨型源码库，如果你不掌握一些高效的方式，那你阅读起来会让你绝望。就像往大海里投个石子，虽能掀起一丝涟漪，但海面很快就归于平静。

其实从整个程序员群体来看，很少有人去学习这些项目的源码，大部分人都仅仅停留在 API 使用阶段。

很多人对某个框架、项目的了解，最多停留在其它人对源码的解读之上。的确，在搜索引擎如此成熟、信息如此多的时代，如果要快速了解信息，以便解决眼前的问题，这的确是高效的方式。

相信有不少人肯定也尝试过去github上阅读那些开源框架的源码，但是坚持不下去。在我看来原因主要是以下几种，

1. 花了好几个小时，甚至好几天，才看懂了1、2个文件里的代码。但是毕竟还得工作呢，按这个进度的话，实在没办法拿出太多的时间放在源码的阅读上，还是算了吧。

2. 第一个选择阅读的项目规模就比较大。一般这种大型项目，必然是经历了多年的迭代而形成的。所以，不管从复杂度还是代码量上都是“困难”级别的。当一次次遇到无法理解而放弃，换一个切入点但困难依旧的时候，你会觉得自己根本无法驾驭它，挫败感会促使你放弃阅读源码这件事情。

3. 有时我们阅读源码会配合着调试。但是有些源码的环境依赖比较多，一旦我们在部署环境的时候遇到了各种诡异的问题，但是查了很多资料依旧未能解决的时候，就会失去耐心，促使我们放弃。

4. 看了一段时间的源码，但是感受不到自己获得了什么，没有成就感。渐渐地，阅读源码的热情逐渐消失殆尽，感觉还是打游戏、刷短视频更香。

不知道上面有你的影子吗？

之所以出现这样的情况，在我看来是因为没有找到明确的方向或者目标太大，阅读源码是为了什么？为了提升自己，但是这个目标太大了，大到你还没有接收到正反馈就坚持不下去了。

所以我觉得有效地阅读源码的步骤分为以下两步，when和how，正好对应上一篇《阅读源码的真正价值》的why。

/01  阅读源码的时机/

很多人看源码之所以看不下去，间接说明了一个问题，并不是任何时候都适合阅读源码。

所以，我们的第一个问题就是要搞清楚“什么时候适合阅读源码”。

我亲测有效的方法是，带着问题去阅读源码，哪怕是一个个看似很小的问题。慢慢庖丁解牛，逐渐吃透整个项目。

举个例子，比如你看到网上很多文章都在说redis单线程的性能表现在某些场景下甚至比多线程的memcached还要好。

那么你可以带着这个问题去找到对应的源码去学习，这比你漫无目的的在大量的源码中乱逛，效果好得多。因为当你阅读完源码后你会获得一个正反馈，就是你知道了问题的答案，这种收获与成就感也会大大加深这次学习的效果。

所以，一定要有一个问题或者说目的，没有目的就不要去阅读源码，还不如打游戏刷短视频。因为你大概率没几天就会全部忘记你看过的东西。

如果你只是想学习一下，实在想不到什么问题作为切入点，那么不妨从git仓库里的issue里找一个开始吧。

/02  怎么读/

01  准备工作

阅读源码之前首先你得掌握相关的基础知识。比如，你要去读Linux内核的源码，但是对C语言并不熟悉，这个事情自然没法继续下去。

在具备起码的基础知识后，先去官网看看是否有什么文档，通过阅读文档可以对项目设计思路和演进思路有一个大致的了解，这对你在实际阅读源码的时候可以起到事半功倍的效果。

还可以了解一下，是否有其他项目是该项目的衍生品。因为当你后续觉得阅读该项目的源码举步维艰的时候，那么不妨试试从封装它的上层入手。多一种选择。

02  从最早的稳定版本开始看

coding和造房子一样，结构（架构）在最开始一但确定好，后续几乎无法推翻重改，所以建议你从第一个版本开始看，可以通过阅读最少的代码就能了解到整个项目大部分的内容，包括它的核心设计思路。

后期追加的很多代码其实有不少都在完善最初设计没考虑周全的地方以及异常处理，代码量虽然增加了，但是重要性完全不同。

03  在IDE阅读

很多高手直接在git上看源码，效果如何我不清楚，反正我是觉得不太靠谱。

Z哥建议你一定要把代码放到IDE里阅读，毕竟IDE里可以方便跳转，查看定义，而且只要环境搭好还可以调试，比起在网页上看效率高得多。

如果你实在要在git上直接阅读，好吧，我也帮你一把，推荐你一个chrome插件：SourceGraph。为你提供接近IDE般的操作体验。

04  尽量调试一下

尽可能编译调试一下。因为在Z哥觉得能调试的代码，几乎没有看不懂的。

很多人在工作中修bug为什么喜欢直连生产环境调试？除了修bug效率高之外，还有一个原因就是它直观的体现了一个完整的流程在代码中是如何体现的。

如果一份代码你只能看不能调试，那可能读到一些地方你只能猜这个地方的数据值和跳转结构是怎么样的，而且很有可能你猜的是错的。但如果你能编译运行，那在需要的时候你可以修改，加日志等等来更好地观察和验证你的想法，得到正确的理解。

05  先从宏观再到微观

在看具体的代码之前，建议你先大致过一下整个项目的分层，知道解决方案里每一个项目的作用是什么。比如，这个专门存放全局工具类的项目，这个是数据访问层，等等。

这样当你在后续经过多次代码跳转之后，不至于晕头转向的。

同样的，在你深入代码细节之前，先从“宏观”入手。先捋清楚与这相关的上下游完整的流程是如何映射在代码里的，然后再开始深入其中的具体环节的实现。

另外，interface也是获取宏观信息很好的入口，当然前提是方法的命名比较规范或者有注释。

06  适当跳过一些代码

一个项目的源码规模越大，里面的能跳过不读的代码也越多。

哪些是可以跳过的？

比如，针对数据的处理，json的序列化和反序列化、xml数据的读取和写入等代码，这些代码往往还特别冗长。

07  看一遍无法理解的代码就画图

当你看一遍甚至好几遍都无法完全明白的代码，说明它具有一定的复杂性。

此时，你不要偷懒，老老实实地画流程图、时序图等来帮助你梳理和记忆。它们最终为你省下的时间大概率比你花的时间多得多。

而且画图是把代码具像化了，当你对着一张流程图读源码，就好像拿着地图走迷宫一般，确保自己走在预期的道路上。

08  做笔记

我相信每个人都出现过这样的情况：

• 这个问题我之前解决过，怎么解决来着？好像想不起来了……

• 这个问题我之前研究过，是怎么回事来着？好像想不起来了……

• 更甚之的情况是，早上觉得弄懂了数据流向，中午吃个饭就忘了。

• ……
  

如果你当时做了笔记，就不会出现这种情况了。而且，做笔记不仅仅可以用做后续的查阅，还可以帮助你更快地进入前一天的阅读状态。

这里建议用纸和笔就好。如果要用软件的话，最好弄个双屏，这样可以避免频繁地在查看源码的应用和记录笔记的应用之间的切换。

我建议你弄明白一个问题或者收获一个新的信息就记录一下。

然后每天工作结束，稍做整理，并且将当前遗留的未知问题记录好，这样你第二天很容易进入到昨天的状态中继续进行。

如果你打算将阅读源码作为一个长期习惯去做，那么你平时储备的通用知识多少又变得很重要，因为它们可以在阅读源码的时候大大提升效率。

比如，设计模型、常用的算法等。当你看到什么XXXbuilder、XXXfactory，你就心领神会了，自然能大大提高阅读效率。

当然，如果遇到你之前不懂的设计模式、算法，那么应该停下来花点时间，将他们消化掉，这样你的通用知识库就又扩大了一些。

总之，阅读源码还是一个比较费神的事情，要有耐心，遇到困难的时候更是如此。

我有时看代码，也会反复好几遍看不明白，感觉真是觉得搞不定了，然而，这意味着要么是你基础知识没准备好，要么是你找错了入口，要知道，任何一份代码，都有一条隐形的线串着，耐心点，总会找到。

好了，总结一下。

这篇呢，Z哥和你分享了我在阅读源码这件事上的一些经验。

首先，一定要带着问题或者目的去读源码，否则就别读了，读源码光“看”是没意义的。

其次在读的时候可以做以下8件事：

1. 准备工作

2. 从最早的稳定版本开始看

3. 在IDE阅读

4. 尽量调试一下

5. 先从宏观再到微观

6. 适当跳过一些代码

7. 看一遍无法理解的代码就画图

8. 做笔记

希望对你有所帮助。

源码一开始读不懂是正常的，读不懂才要读，想不明白才要想，这是进步和成长的开始。那些阻挡你的蹂躏你的而又杀不死你的，终将帮助你成长让你变得更强大。