需求¶
源码源码算是打工人对于技术最后的追求或者是内卷的手段的必备技能。因此，阅读开源项目也算成为了打工人的必备技能。那么这篇文章也就应运而生了。本文目的有二：一是整理学到的方法论，集百家之长，指导自己的学习；二是作为整理后的产物，输出保证学习的效果。
阅读文档¶
遇到一个全新的项目或者代码，最先做的应该是对整体有一个了解。最简单的方法就是先去查看相应的文档。有官网的quick start之类最好。明确这个项目的结构，有哪些功能特性，知道它涉及的关键技术、实现原理、生态等等。其实这个过程类似论文的摘要。先不要直接就上来看代码，这样容易陷在细节中。
另外针对这里的文档，优先推荐官方的文档。不要因为是英文的，就选择去找中文的材料。原因就不赘述了。即使真的需要中文，也推荐去找对应的中文版本，再去过一遍官方的英文版本。总而言之，阅读官方英文材料。
在了解项目怎么使用之后，可以找一下Introduction。这是因为很多开源项目喜欢有一个单独的Base Concepts，它们会发明很多概念。需要现在学会它们的“方言”，才能更好理解它们的描述。
在阅读完项目的整体介绍和关键技术后，就需要了解它的生态，一般项目本身会介绍典型的适用场景。现在的技术本身都是trade-off之后的结果，并没有“银弹”的存在。因此每个技术都有其适用场景，这个也是技术选型时主要依据。
在完成上述阅读后，应当对下面的问题有一定的了解：
- 这个项目是干什么的？
- 能解决哪些问题？
- 适合在哪些场景使用？
- 有哪些功能？
- 如何使用？
阅读相关文献¶
在完成文档的阅读后，不应该是直接去阅读论文。往往一个新项目的广泛使用，其背后都在依托于有那么一群科学家针对某个问题，提出了一个解法，这个方案得到了大厂的认可，于是工程师将理论落地，最终变成了耀眼的开源项目。
虽然理论和工程之间一直存在着gap，但是这并不影响论文的重要性。但是这也反向告诉我们，阅读相应论文的时候也是先从整体掌握，而不是拘泥于细节。很多论文中着重描写的结构或者算法，可能在工程侧是完全不同的实现方法。但是其主要思想是一致的，只是实现方式或者方法的差异，算是条条大道通罗马？
因此，项目背后的论文是项目的灵魂，其优先级高于源码。
以点带面读源码¶
终于到了阅读源码，但是源码的阅读也不是直接main开始生啃。
推荐的阅读方式是带着问题去读源码，最好是带着问题的答案去读源码。
类似这种非常细粒度的问题，粒度细到每个问题的答案就是一两个流程就可以回答，这样就可以了。如果说你就想学习一下源代码，或者说提不出这些问题怎么办呢？答案还是，看文档。
确定问题后，先不要着急看源代码，而是应该先找一下是否有对应的实现文档，一般来说，核心功能都会有专门的文档来说明它的实现原理。更为细节的实现原理，可能没有专门的文档去描述，这时候就需要去寻找Improvement Proposal。往往会采用项目首字母加所写的方式表示，比如Kafka项目往往会有KIP去描述一个新功能的文档。
每个 Improvement Proposal 都是有固定格式的，一般要说明为什么需要增加这个功能，会对系统产生那些影响和改变，还有我们最关心的设计和实现原理的简述。
你读完讲解实现的文档再去看源代码，也就是我刚刚说的，不只是带着问题去读，而是带着答案去读源码。这样你在读源码的时候，不仅仅是更容易理解源代码，还可以把更多的精力放在一些实现细节上，这样阅读源码的效果会更好。
使用这种以问题为阅读单元的方式来读源代码，你每次只要花很短的时间，阅读很少的一部分源码，就能解决一个问题，得到一些收获。这种方式其实是通过一个一个的问题，在网状的源代码中，每次去读几个点组成的那一两条线。随着你通过阅读源码了解的问题越来越多，你对项目源码的理解也会越来越全面和深入。
总结¶
最重要的是，要在项目学习后，把主要的流程用流程图或者时序图画出来，把重点的算法、原理用文字写出来。
