最近这段时间一直比较忙，相对于之前少了很多的学习时间。抽空看几篇源码分析的文章，大多数都是大同小异的思路，把英文翻译为中文而已。鉴于关于介绍如何阅读开源项目的文章比较稀少，常言道授人予鱼不如授人予渔。希望这篇文章能够给准备阅读三方源码的同学一些启示。
目的
在阅读源码之前最好明确一下阅读的目的，这样有助于阅读的深度和时间的控制。比如如果是为了解决项目中的bug，则可以阅读bug所涉及的部分；如果是为了提高自己的编码能力，学习设计技巧，则就需要更为深入的阅读。
因为阅读源码其实是一件非常辛苦的事情，尤其是分析一些大型开源项目的源码，如果毫无目的的阅读会浪费大量的时间。而且阅读源码也是一个长期的过程，不可能一天分析完Spring源码的分析，所以在分析源码之前一定要有一个明确的认识，不仅仅只是翻译英文注释，花大量的时间是在所难免的。
对笔者而言阅读源码的目的基本上可以分为如下几种：
- 提高自己的编码能力，学习设计思想。
- 解决工作中所用第三方库遇到的bug。
- 借鉴开源代码，私有化别人的代码，完成工作需求。
当然不排除某些大神，读源码纯粹是了找开源代码漏洞或者想改进该项目。毕竟这种牛逼的人是少数。当我们明确了阅读的目的就可以大致确定所需要花费的时间及精力了。
源码获取
获取源码的地方太多了，最负有盛名的就是GitHub。除此之外还有sourceforge，Google和Apple也有其开源项目下载地址，分别是Google OpenSource、Apple OpenSource。国内有比较出名的有开源中国，码云(开源中国代码托管平台)），Coding。
整理一下：
在进行搜索的开源项目有很多搜索技巧，就拿GitHub举个例子。想高效的使用GitHub，一定要把 advanced search、prefixes看一下。
除了上面提到的开源项目下载地址，还有很多其他的地方可以获取到源码，这里就不多提了。
分析方法
阅读方法才是今天的重点，笔者一般是按照下面的步骤开始。
- 基本思想就是先对项目有个大致的了解。比如关键的类有哪些，各个文件夹之间的关系。
- 然后从最核心的API开始，先使用UML里的类图建立静态结构，分析出类与类之间的关系（继承，组合，实现，依赖，关联等等）。这一步是精读的必经之路，如果想要彻底理解，画UML图无意识最直接的方式。
- 配合IDE工具分析核心流程，理解项目是如何工作的。
- 着重看项目中添加的注释，因为一般开源项目中的注释都非常重要。
接下来分下面几个部分详细介绍。
- 看：静态对代码进行分析，看相关资料，代码逻辑
- 跑：将项目在IDE里面跑起来，通过IDE调试参数，加Log等。
- 查：阅读过程中肯定会遇到不懂的，这时候需要通过搜索引擎来解决你的疑惑。
看
这个部分是非常基础但是重要的部分，主要完成对代码的基本感知。从静态的角度理解代码。
现有资料
在我们准备阅读某个开源项目之前，如果搜集了相关的资料的话，对我理解起来非常有帮助。也就是常说的站在巨人的肩膀上。
主要分为两种：
- 项目官方文档比如Wiki
- 使用者分析的文档比如项目源码分析。
GitHub上的开源项目大部分都有文档介绍，好一点的项目都会有对应的Wiki。除此之外开源项目的Issue也是我们需要关心的。往往这些Isuue对应到项目中都是核心部分，也就是我们非常值得关注的地方。如下图所示，一定要善用这些选项。因为这些都是前人踩过的坑，对于项目理解非常有用。
除了项目本身的文档外，还有一种形式的文档也需要我们注意。这类文档就是别人对这个项目写过的一些源码分析文章。这类文章已经对项目分析过一次了，先阅读完之后，会对我们自己去阅读源码起到一个理清思路，引路的作用。
但是有些大型的开源项目文档太多了，就官方说明文档就不可能一次看完，比如java中的Spring，看完文档也是不现实的。这个时候就应该把文档与代码调试结合在一起。效率会高不少。而且这类型的大型项目至少也得花一年半载才能弄清楚。
代码内注释
对于开源项目内注释一定，一定要仔细看看。在使用第三方库的时候，往往因为没有仔细阅读代码内注释而导致滥用方法。
如下图是iOS开源项目CocoaAsyncSocket一段代码内注释
如果没有仔细看代码内注释，没有注意到必须设置代理和代理队列，遇到报错了根本不知道怎么发生的。
代码内注释是作者着重想传达给使用者的信息，所以切记切记，一定要仔细看代码内注释。但是好多人都误以为把注释看懂就是源码分析了，而且好多源码分析文章也是这样写的，把注释翻译一下，说明一下用途。
跑
这个过程是对代码的深入理解部分，通过改变函数参数，运行环境等。不同的语言用了不同的IDE，大部分IDE的作用都相差不多，都可以追溯堆栈，查看变量信息等。所以思路都是相同的。
IDE调试
项目编译出来，运行加log，试着修改一些数据和代码，看看有什么变化。这是最为常用的方法。灵活使用IDE的debugger，而debugger最重要的功能是获取call stack。查看变量的变化情况，在你不知道有什么用的函数里加个断点，显示出来的call stack都能让你对系统有更清晰的认识。
关于IDE的调试使用常用的断点调试，变量跟中这些，这里就不多讲了。
调试技巧
很多时候我们不知道某个变量或者某个变量具体的作用，那么这个时候就可以用到对CUD（Create,Update,Delete）思想。
调试中的CUD具体来讲就是对源代码的类、函数、变量进行增加、修改、删除。如果一直停留在看源码的基础上很有可能不能透彻的理解，当我们掌握了代码设计规则，使用CUD方式可以加深理解，以及验证我们的猜想是否正确。
特别注意，在实现项目中一定不要去修改第三方的源码，有时候可以通过修改第三方源码来达到暂时的目的，但是往往在后期维护，升级方面必将付出惨重的代价。这里指的CUD只适合在分析源码的时候。
查
在分析源码的过程中，肯定会遇到自己不懂的地方，对于这种问题，大部分靠自己现有的知识很有可能无法理解，这个时候就需要实在不懂就问了。Google、相关社区、GitHub Issue、Stackoverflow多搜多问。
查这个步骤应该是贯穿整个过程的，但是也得注意不是一遇到问题就上网查，而是应该在自己思考之后，得不到解答才去查。很多同学养成了一遇到问题就Google，百度，其实从长远来看不利于自己的提升。
分析总结
走完上面的步骤之后，基本上对一个项目源码掌握了。但是这个层次还是有点low。仅仅停留在理解的阶段，如果想做得更好就需要对项目的设计进行分析，看看有没有可以改进的地方，甚至完全试一试自己能不能针对某个模块改进一下。
这个阶段类似于提升、创新的程度，建立在见多识广的基础之上，对于阅读开源项目不多的同学还是非常有难度的。
整理成文
最后的阶段就是把自己分析的内容整理成为文档，分享出来。这也是提升自己能力的一个重要渠道，在写文章的时候，会强迫自己对那些不清楚的知识点加深理解。
文章内容应包括自己整理的UML图，核心类的实现，代码设计技巧，以及告知读者使用该第三方的时候需要注意的问题。
在写文章的时候需要注意，不要过多的延伸。毕竟一个点所涉及的知识网太大了，选择其中比较核心的几点阐述即可。
