我开始阅读源码是在进行互联网开发的第八九个年头。在此之前，我做过校园网站，接过网站开发的私活，进行过理论算法相关的研究，也设计开发了许多系统。我对我做过的系统都比较有信心，它们也都运行的不错，但是一个疑问却在我的心头逐渐浮现：我的架构和世界最优良架构之间的差距到底有多大？
阅读开源项目的源码能给我答案。
许多优秀的开源项目历经数千开发者的数万次提交，被数亿用户使用。这些项目从可扩展性、可靠性、可用性等各个角度考量，都是十分优良的。通过阅读这些项目的源码能让我找到自己在软件设计和开发上的不足。
于是我开始了我的源码阅读计划。
阅读源码的好处很多，而且已经成为共识。光靠铺天盖地的源码阅读活动就能感知一二，虽然我觉着那些活动都太过浮躁，主要是个噱头，学不到啥。
但是不可否认，阅读源码的好处极多，包括但不限于：
所以，我有些后悔，我觉着我应该更早地开始源码阅读。我推荐进行源码阅读的时机是：学会编程语言的基本知识，并做过少量项目之后。
我们知道，学编程的过程中在不断接收新的知识，进步很快。刚开始做项目时，进入实践领域，进步很快。然后就到了平台期，可能几年下来都是重复的增删改查，毫无进步。这段平台期实际是进行源码阅读的良好时机，能让你的技术持续进步。
当我们阅读一份源码时，需要面对的困难通常有：
所以很多人即使知道阅读源码的好处，也坚持不下来。就因为以上困难难以克服。
而阅读源码的难，是正常的。
3.1 时间维度带来的困难
从时间维度上看，每一个优秀的工程项目都经历了从雏形到成熟的曲折演化过程。而整个过程都会被映射到一个时间点上，肯定很难。
于是有人提出了“阅读源码时，从第一次提交开始阅读”的主意。我要说一下，这是错误的！
这是一种纸上谈兵式的错误，提出这种方法的人肯定没怎么读过源码。事实上，我也有过这种想法，然后在实践中很快被抛弃了。
如果一个项目只经过了几次提交，这种方法获取可行。而一个优秀的通常有几千上万次提交，将这几千上万次提交都读完，工作量要比把当前最新版本的代码读完难的多得多！因为其时间维度的复杂度比空间维度复杂度大得多了。
我用下面的图片展示了项目发展的过程，一个项目从版本1到版本n，逐渐完善。版本1一般是最简单最基础的，但是，要想从版本1读起，一直读到版本n，可能要阅读几千个版本。难度极大，远不如直接去读版本n。
还有，许多项目的第一次提交并不是只有几行代码的init项目，往往第一次提交就是几百个类。而且，初期的代码组织还比较混乱。毕竟，作者也不知道该项目能火，往往比较随意。
更别说，历史提交中还夹杂很多的Bug、回退、依赖包升级等等。想要把每次Bug、回退、依赖包升级所产生的历史背景都搞清楚，这几乎是不可能的任务。
3.2 空间维度的困难
每一个优秀的工程项目都凝聚了众多开发者的缜密思维逻辑，而这些逻辑都被投射到了平面的代码上。这使得阅读源码的过程成了逆推开发者思维逻辑的过程，显然，逆推是很难的。
不过，这方面的困难真有解决方案：详细了解开源项目的功能，然后自己琢磨该如何实现。
这样，就将逆推 的过程转化为了 正向推导+验证 的过程，这样就相对简单了。
但无论如何，阅读源码总不会太简单。于是有人说读懂源码比编写源码更为困难，想必也是有一定道理的。
阅读源码推荐按照下面的步骤进行：
一般情况下，一个项目的源码要在3~4个月左右读完。否则，可能读到后面的，已经忘记前面的功能了。
当然越快越好，但考虑到我猿们还要加班，时间太短了不太现实。
有人说读懂源码比编写源码更为困难，不无道理。而源码阅读和软件开发一样，是一个非常综合的能力，没有一个万全之法。但有很多不错的方法。
例如一些常用的方法：
还有很多方法，不再一一介绍。因为没有实在的源码案例，光介绍显得很浮。
如果大家真的决定阅读源码，开始提升自己架构能力和编程能力的新阶段，可以阅读《通用源码阅读指导书——MyBatis源码详解》。
是一本以MyBatis源码为材料，详细介绍源码阅读相关方法和技巧的源码阅读指导书籍。
该书以实际开源项目MyBatis为例，详细介绍了源码阅读的经验和方法。在源码阅读中，透彻分析了相关的背景知识、组织方式、逻辑结构、实现细节。在本书的讲解中，不漏过每一个类，不跳过每一个难点，做到深浅一致。并对这些源码阅读方法进行了进一步的总结整理。
阅读源码会使你有很大的提升，但是这个过程也确实需要你沉下心来慢慢进行。
但我保证，只要你读完一个项目的源码，就会收获巨大。
最后，用书籍前言中的一句话结尾。
