15个小技巧包括:

  • 了解作者开发项目的目的

  • 先熟练的使用项目

  • 阅读官方文档

  • 理解项目中的概念

  • 了解项目技术背景

  • 没必要读最新版本的代码

  • 不需要读完所有的源码

  • 版本间比较阅读

  • 自顶向下梳理

  • 自底向上归纳

  • 先做减法,再做加法

  • 从接口找关系

  • 画图辅助阅读

  • 设计模式辅助阅读

  • debug只是辅助

下面来一个个的阐述。

了解作者开发项目的目的

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

  • 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个能提高源码阅读效率的小技巧。下面我们将正式进入源码阅读流程的讲解部分。

02-26 14:31