谈谈加速源码理解的几种方法

尝试总结一下本人在看Spring，SpringMVC，Tomcat，Mybatis，Druid，Log4j2等源码过程中的一些基本核心理念。知晓它们能加速你对源码的理解。

1. 拦截性接口和事件通知

• 在重要的过程上设置拦截接口
• 重要的状态的变更发送事件并留出监听接口

梁飞大神在发表于2010/7/5的博客一些设计上的基本常识 里完整详尽地阐述了这两个观点（虽然2010年这篇博客就发表了，但本人直到2016年才看到这篇博客，真是相见恨晚）。这也是当时本人入行四年来极其少有的看到有人愿意如此透彻明了地讲述一些根本性的理念，一点都不藏着掖着（上一次能给予本人以类似重塑三观的观点的是在SICP一书中）。 强烈建议各位去拜读下这篇大作。虽然时隔快八年了，但其中阐述的“道”是历久弥新的；在现在层出不穷的”新“框架里新瓶装着这些老酒。

在阅读源码中，你会发现这两个原则或原模原样，或多穿件衣服一而再再而三地出现在你面前。

其它的诸如“平等对待第三方”，“微核+扩展”等我就不越疱代俎了。总而言之，这篇文章能直接带你进入快车道。

2. 带着问题去看

老生常谈；但是我还是得强调一下。因为读源码不是我们的目的。拿Spring举例，我在阅读完Spring的核心实现之后， 就很少主动去看Spring相关的源代码了，只有在碰到相关问题时，才会刻意去读下相关的实现。

绝对不要漫无目的地去阅读源码。关于这一点就不展开了。

3. 忽略细节

本人一再强调知道自己不该自己什么同等重要。要学会容忍混沌，这是一种普世的哲学。

软件由无数的抽象层叠加而成，不论你当前处在哪一层，往下看你都将看到黑盒。所以知道自己该在哪里停下显得尤其重要，甚至相比较知道自己该知道什么而言更重要。

4. 考虑从低版本入手

可以故意读一些低版本的来降低难度。当然前提是Spring这种平滑过渡的。那种暴力升级的框架还是老实跟着最新版本跑吧。

5. 学会看堆栈

这里就不废话了，直接上图，这是本人最近在写SpringMVC源码相关博客时的截图，通过跟踪相应的栈帧，我们可以快速地定位到我们所关心问题的可能出处。

DispatcherServlet堆栈

6. 画时序图

2017/12/18补充

把非常重要的一个方法给忘记了！本人看的第一个源码就是Spring。而在看Spring源码时本人连Spring的Hello World都写不出来，而是直接抄起一本《Spring源码深度解析》就开干了。

刚开始为了“节省时间”，直接一页页地翻，到100多页时就彻底跟不上了。无奈之下，从头开始，跟着作者的步伐走，学着去画时序图。

两年后的现在，如果让我重新选择的话，我会第一时间打开PowerDesigner新建一个时序图的画布。

7. 关注命名

2018年4月26补充

关于代码编写规范的书籍和文章有很多，它们中彼此之间的有些观点不尽相同，极端点的时候甚至向左。而对于命名方面，这些书籍或文章却都无一例外地将其摆在极其重要的地位。

一个优秀的，经过时间考验的框架，其命名必然是被反复检验过的（所以个人认为，阅读源码除了理解它们蕴含的理念外，它们的命名也是非常值得学习的，鄙人就专门有一份笔记记录着从各个源码收集来的命名），是非常值得我们投入精力去关注的。例如上面第三条里的“忽略细节”，当我们忽略细节之后，必须得有些事物来协助我们，帮助我们理解这堆代码是在做什么。而命名此时正是我们的得力助手，好的命名能分担绝大多数的注释，Bob大叔甚至认为代码里的注释应该尽最大可能用命名代替。他提出“不要双语种编程”——英语也是一种语言。当时阅读完《Clean Code》，鄙人整整半年没写过注释。

说了这么多，其实就是为了强调，利用好源码里的命名，可以让你对于源码的理解将更上一个台阶。

8. 善用grep命令

2018年12月01补充

有时候即使使用IDE来进行源码阅读，有些类的引用情况或者Constant字符串（例如一些框架打印出来的日志，我们尝试进行反向追踪时）的引用我们也未必能百分之百地进行定位，我们一般只能大致确定其所在的package， 甚至只能确定到jar，这会让我们感到很被动，此时如果能借助Linux命令行工具的话，这些问题就能引刃而解了。

// 在spring-rabbit源码路径下执行命令，我们就能准确定位Rabbit关闭Channel的逻辑和时机了： 
grep -irn 'Closing cached Channel' org