15个小技巧包括：

了解作者开发项目的目的

我们都知道「软件是工具」，是为了解决某个或某些问题的：

• IM解决了人们在网上沟通的问题
• 淘宝解决了人们在网络上购物的问题
• 支付宝解决了无钱包支付的问题

了解了一个项目的目的，也就清楚了项目所需要解决的问题。如果你熟悉这个问题所对应的领域，你就能大概知道这个项目有哪些功能模块。比如淘宝是购物的，那它至少得有客户管理、商家管理、店铺管理、商品管理、商品购买、购物车等等模块。
即使你不熟悉，你在通过该项目的学习后，在后面阅读其它类似项目时，也能有事半功倍的效果。

先熟练的使用项目

在阅读源码之前，你需要能熟练的使用项目，不仅仅是写个demo跑一下！你需要在实际项目中去应用。你需要能够摸清开源项目有哪些功能。你越熟悉项目，你阅读源码的难度就越小。

就像组装电脑一样，你连主板、显卡、电源都还傻傻分不清楚，你怎么去组装电脑呢？更别说去自己做一个电脑了！

阅读官方文档

可能大家都喜欢通过实践的方式去了解一个项目，因为更直观。但是，实际上了解项目最好的方法是阅读官方文档。对于一个项目来说，最了解这个项目的人是谁呢？当然是作者本人。文档就是作者通过文字的方式告诉你项目的结构、具体解决的问题以及怎么解决的。好的项目都会有比较完善的文档。

另外通过实践的方式了解项目是一个摸索的过程，可能会有遗漏。而文档能给你一个全面的了解，能够弥补这些遗漏。

理解项目中的概念

一个项目一般都会有一些自己的概念或者基于某些理论、模式来构建，理解了这些概念、理论和模式，能帮你更好的理解项目代码。

比如你不了解NIO以及Reactor模型，那你读Netty源码可能就非常的吃力。你不了解生产者、消费者、Broker、主题、分区、副本这些概念，你读Kafka源码就很吃力。

了解项目技术背景

你有没有发现其实很多项目的迭代，其核心功能并没有发生什么样的变化，变化的可能只是实现方式的不同。频繁变化的实际上不是需求，而是实现需求的技术！
就以「移动网络的技术发展对娱乐所产生的影响」来说。
在我刚上大学的时候，手机还是2G的，当时的娱乐方式就是看看文字小说、听听mp3、看看mp4！因为2G网速的限制，当时所做的应用有这么几类：

• 省流量的浏览器，能自动屏蔽图片，加速网站的打开
• 音频视频转换压缩软件，方便拷贝到手机上
• 方便的将mp3、mp4拷贝到手机上的软件

然后3G出来了，每个月的流量也按G来算了，图片什么的所消耗的流量也就不那么在乎了，所以省流量的浏览器的作用就越来越小了，取而代之的是功能齐全的浏览器，能自动适配手机，快速打开各种图片。但是听歌和看视频还是以拷贝为主，因为毕竟一个月流量也下不了几部电影，且3G速度还不支持高清视频的在线播放。

接着4G来了，每个月也不限流量了，于是听歌、看视频都能在线看了，优酷、土豆这类视频类网站开始多了起来。而视频转换类软件以及文件拷贝类软件就很快销声匿迹了。

现在5G要来了，它会以什么样的方式来影响我们的生活呢？现在还不得而知。不过你可以发现，无论技术怎么变，我们的娱乐方式其实没怎么变化过，无非就是看看小说、聊聊天、看看视频、听听歌，但是随着技术的发展，实现的方式产生了变化。

项目的发展也是类似的，核心的功能并没有多少变化，主要是实现技术的变化。所以在阅读源码的时候，了解一下当时的技术背景，知道当时的技术限制，才能更好的理解代码为什么这么写。

这就像很多人刚进入一家新公司，抱怨说公司的代码太烂了，觉得还不如自己写的。如果你了解一下当时的情形，可能会发现这么写是最优的。

没必要读最新版本的代码

很多人读源码都喜欢下最新版本的代码来读，因为里面使用了最新的技术。但是，新版本的项目无论从功能还是代码量上，都比老版本多得多。
以Linux内核为例，目前Linux内核的代码量已经超过了2500万行，就算你一目十行，那也需要250万秒，也就是说你要不眠不休看将近29天才能看完！

实际上无论发布了多少版本，它要解决的问题基本不变。所以你可以找一个相对老一点的版本来阅读，理解了它的核心功能以后，再慢慢的进行必要的额外功能的源码阅读。

不需要读完所有的源码

不知道你读书的时候有没有这种心理，就是书里的每个字都读完了，你才认为读完了一本书，如果没有读完，你心里就特别的纠结？其实没必要，书是作者在阐述自己的观点，你只要get到他的点，并且有自己的看法，那么你实际上就已经收获了书里的精华了，没必要每个字都读完。

其实书里的很多话都是废话，或辅助，仅仅是为了更好的阐述那个核心观点。源码也是一样，大部分的代码都是为了辅助核心代码来完成核心逻辑的，没必要一字不落的将所有代码都读完，效益比不高。你需要学习的是设计思路。

版本间比较阅读

前面说，项目的不同版本可能技术上、实现上有差异。通过比较阅读的方式，能够发现这些差异，再结合自己的思考：

• 为什么有这些差异？
• 哪种实现方式好？
• 哪种实现方式不好？
• 好在哪里？
• 不好在哪里？
• ……

你就能更好的理解项目设计思路。同时，如果你已经读完了一个版本的源码，那么基于这个版本的源码再去读新版本的源码会更加的容易。

自顶向下梳理

越上层的模块，功能越多，但数量越少。我们可以从顶层的模块梳理出大致的流程关系，然后通过不断的深入，来梳理细化流程。就像思维脑图一样。
后面的文章会具体的讲解如何梳理这些模块。

自底向上归纳

思维脑图的一个问题就是「只管拆分，不管归纳」！归纳其实是非常重要的一环。当你梳理了细化的流程后，需要将细化流程整合归纳到整体流程中，通过不断的归纳，你才能理解整体的流程。

后面的文章会具体的讲解如何归纳总结，将细化的流程整合到完整的流程中。

先做减法，再做加法

前面说了，无论项目代码多大、版本怎么变化，核心的功能是基本不变的。所以我们先自顶向下的去不断的剔除非核心的组件/包/类，找到核心的模块/包/类。梳理出核心流程后，在核心流程的基础上再进行扩展，引入其它流程，以构成完整的项目流程。

这也是本专题将要介绍的方法，后面会详细说明和演示。

从接口找关系

个人认为「接口」这个词并不好，应该叫「协议」更合适。接口定义了一套可供外部访问的方法，其实就是交互的协议，外部对象、模块或者系统需要按照这个「协议」来访问我们的系统，所以我们可以从接口的调用关系，来梳理出模块之间的调用关系。

后面的文章中将具体演示梳理方法。

画图辅助阅读

有研究表明，我们接收的大部分信息都是通过眼睛接收的。绘图能加强我们的理解。同时，绘图相当于是有了存档，当再次看到绘制的流程图或结构图时，能快速的唤起你对项目的理解。

设计模式辅助阅读

之前写了一篇文章「从架构层面看设计模式」，通过对策略模式的讲解，阐述了设计模式对架构的影响。如果你很熟悉设计模式，你就能从代码中的设计模式梳理出代码结构，也就能加快你对源码的理解。

debug只是辅助

从「想读项目源码？可为什么总是读不下去？」这篇文章中，你应该能体会到直接使用debug的问题了。所以不要一上来就debug，debug是在你理解了项目结构和流程后的一个验证手段，或者确认某些具体细节的方法。如果一上来就进行debug，你就会陷入「想读项目源码？可为什么总是读不下去？」这篇文章中提到的死循环中。

通过后面文章的学习，相信你能学会正确的使用debug的方式。

总结

本文梳理了15个能提高源码阅读效率的小技巧。下面我们将正式进入源码阅读流程的讲解部分。