只列提纲

只列提纲但是可以是密密麻麻的提纲。提纲也可以是问题，学会提问题。

1. 为什么要读源码：
   1. 优秀的源码可以映射到读者的脑海中，形成优雅的框架，并且可以帮助理清底层的应用问题，便于读者使用对应软件。
   2. 在巨人的肩膀上学习，时刻更新自己的知识库，更新自己对设计模式，编程范例，代码设计，领域划分和架构的理解。
   3. 扩展知识边界：从上层应用到底层的代码设计，里面有层层叠叠的知识，如果时间足够，可以从应用编写一直到汇编语言和webassembly等底层应用，甚至可以到boot的系统启动和硬件设计。
2. 源码阅读的选择：
   1. 选择开源的，有着优异性能特性的开源代码。
   2. 选择有特定领域下的代码功能特性的代码，例如Redis中的set结构，redis中的跳表结构，时序队列中的改进的跳表等。
   3. 特殊的框架和特定环境下的单一应用，例如etcd，例如分布式的特性和原理分析。
   4. 备受称赞的整体系统内容：例如xv6等小型的麻雀化的操作系统，可以快速学习和了解操作系统的一些功能特性。
   5. 选择自己能够看懂的源码分析，以及源码的开源应用。在最早期的时候，不学习极度复杂的代码，例如初学者直接去阅读openstack的代码，kubernetes的代码，那么就是难度极大接近不可能的任务了。
   6. 学习redis和nginx的部分源代码结构，或者能够写一个基本的，基础的代码可以接受的。

环境准备

1. 准备好能够运行软件的环境，以及debug的环境，能够跑起来代码，尤其是一个系统型软件的时候，能跑起来是必要的，很多时候debug也是需要专门的环境，例如x64debug，例如gdb，例如内核的调试符号。等等。

2. 准备好阅读用的IDE，方便看代码函数的时候快速的跳转。

3. 借助最新的AI技术，可以快捷的理清代码中的层次结构，甚至可以了解运行流程和方式。

4. 结合上下文来阅读代码。

5. 与应用软件交互的方式来阅读代码。

了解模块间的依赖关系与边界

大项目中会包含许多模块，一个模块经常只拥有单一职责。 这有助于我们减少代码复杂度，在适当的层级上做抽象。 模块的接口是抽象的边界，我们可以一个接一个地阅读模块。 如果你在阅读一个使用 Make 构建的C/C++项目，Makefile 是了解模块间如何组织的好切入点。

边界本身也很有用。优秀的代码组织得很好，变量名与函数名的命名风格体现着可读性。 你不需要阅读全部源文件，你可以忽略不重要的或你熟悉的部分。 如果你确定一个模块是仅仅是为了被解析而设计的(just designed for parsing)， 那么你已经大致了解了它的功能；那么你就可以跳过不读这个模块。 当然，这将大大节约时间。

使用源码中的测试用例

测试用例也是帮助代码理解的一个很好的补充。测试用例就是文档。 当你在阅读一个类时，试着把对应的测试代码一起读了。 测试用例能帮你弄清一个类的接口，和该类的典型用法。 集成测试用例可以让你顺着走过程序的整体流程，适合输入一些特殊值并 debug 运行。

增加点评字段

为什么不在花了不少时间阅读一个项目后，写一篇代码点评呢？就像写一篇书评一样。 你可以写下代码中好的和不好的部分，还可以记下你从中学到了什么。 攥写这类文章可以帮助你阐明自己的理解，也有助于其他人阅读源码。

上面是阅读源码的其中一种方式，可以按照这些流程，良好的阅读出代码，并且将代码的可用性放置在上面。