<aside> 💡 无论接手一个新的项目，还是去了解某些框架的底层设计，基本上都会经过一个步骤——阅读源码。随着我们阅读源码的过程，我们也会由于阅读目的、顺序和时间分配等，造成我们无法真正理解源码的大体设计和一些细节处理，导致我们很大程度上都会像无头苍蝇般在那里 scroll + file jump ，所以我简单来分享下自己在阅读一些项目和 library 时候的一些比较好的实践。
</aside>
阅读源码的第一个步骤，那就是你能跑通它，不然以下说的东西毫无意义。这里说的跑通，指的是
先介绍一下我们阅读源码过程中经常使用的阅读顺序。没有最好的顺序，只有最恰合目的的顺序。
打开一个文件，然后再打开这个文件里其他引用的逻辑，那就继续向下搜索，知道看到没有引用其他逻辑那个比较“纯”的逻辑。这种方式很像我们在 debug 的过程——从调用栈底部到栈顶，和套娃似的，一层层的把源码拨开。递归阅读就和他的名字的一样，深度优先，疯狂地为了追求某一个分支功能的结果，这样做对于整体阅读来讲效率是极低的
光想而不记录的思考过程是无意义的，没有思考过程的想法，所产生的结论也无法说服自己，而别说是说服他人。所以在阅读的时候，一定要及时对自己的理解进行具像化。
最推荐的记录方式。当我们在阅读一个源码的时候，我们最好去画一个流程图或者说框架图，可以用流程图来表达数据的流向，框架图来表示各个逻辑包含和被包含关系（一个是数据流向、一个是模块间关系）。一张图在能够使我们自身加深源理解的同时，也可以很清楚的知道源码阅读进度。
我之前打算写的是“笔记”，但想想还是算了。在阅读某些项目和库的源码中，会遇到一些很诡异的逻辑，如果说是这样的话，那要去在代码中补充文字说。当然，如果代码中已经存在注释了，如果不太好理解的话，建议还是用自己的想法在下面也备注一下，毕竟你都觉得他写的注释不好理解，其他人肯定也有这么想的。