笔者之前的博文都偏向于源码分析，因为平时，笔者喜欢钻研技术，阅读项目的源码以窥其内部原理。阅读源码，是工作中不可缺少的能力，同时，也是技术积累的重要手段。阅读源码，一方面可以加深对所读项目的理解，另一方面，也能从中学习到一些技术，提升自己的技术能力。
1. 阅读经历阅读源码也与笔者的工作经历有点关系。
笔者刚参加工作时，先进入一家外企。项目的研发在美国，维护在国内。所以虽然笔者是以码农的身份进入的，但是其实干的是帮助客户解决问题的事情，有点类似售后维修，但是是从代码层次的。因为我们前面还有一个部门叫技术支持，他们会帮客户解决大部分不涉及代码的问题，最常见的就是配置问题。如果他们搞不定，就交给笔者所在的部门了。然而组里的文档也很缺乏，所以每次有客户报的问题过来，必然需要自己去阅读源码。那时候就掌握了一些阅读源码的技巧，并不能盲目阅读。
在这一组工作了两年，锻炼了自己阅读源码的能力，同时也培养了自己钻研技术的兴趣，每次通过自己读源码解决问题时，就有一种成就感。后来转到另一组开始了开发生涯。同时自己也会在工作之外读一个开源项目的代码，比如redis。哈哈，当时把redis源码读的很熟，我记得当时redis新版发布后，听说上了一个新功能，就赶紧去把源码下下来，搞明白redis的实现。
又呆了两年后，跳槽去了国内某一线互联网大厂。进去后领导说当时对我最深的映像就是redis很熟。在该大厂工作，是在算法工程组，以工程为主。在该组，主要涉及到向量检索的工作。工作中主要是利用公司内部实现的分布式版faiss去完成业务需求，faiss当成黑盒使用。但是笔者当时还有个角色，帮助组里同学配置分布式版faiss。因此如果对faiss比较熟悉，那么相关的参数配置就会更合理。因为组里没有人研究过faiss。所以笔者自己去读了faiss，hnsw等向量检索库的源码，并在公司内做了分享。同时，笔者将相关阅读收获撰写成博客（见笔者之前的系列文章）。
后来跳槽去了另一个互联网大厂，进入公司的第一个工作就是负责相关业务的降级。熟悉降级的同学应该清楚，降级需要熟悉业务，才能知道哪些地方可以降级。因此笔者抓紧时间把所在的组相关的业务代码梳理了一遍，整理出降级方案，并在春节期间让业务平稳过渡。
2. 阅读要点所以，从笔者的工作经验来看，阅读源码的能力至关重要。那怎样去读源码呢？
笔者总结大概有以下几个要点：
- 先让程序跑起来。让程序跑起来有两个好处：
a. 看到实际的运行demo，增加自己的信心，也让自己对项目有个大致的印象，知道是干什么的。
b. 如果后面阅读源码有搞不明白的，也可debug。 - 如果是开源项目，去网上搜一些资料。如果是公司内部的，也可以在公司内网搜搜看有没有相关的资料，了解一些项目的大致结构，增加对项目的了解。
- 看文章只能有个大概的了解，要想深入，这时候就需要从入口处去阅读源码了。先梳理一些大致的步骤，不要过度沉入细节。沉迷不可自拔时，很容易放弃。这时候可以自己画一画结构图，或者思维导图，帮助梳理。
- 梳理完大方向的步骤后，可以深入细节，看看具体怎么实现的。有时候，细节不容易阅读，可以利用工具加断点，debug，一步一步。举个例子，笔者阅读KiteX框架的时候，一直不知道ctx在哪里被填值的，只看到一个initRPCInfo，但是这个只是连接到来时初始化ctx，并没有填值。当时就是用Goland在onRead处加断点一步一步走进去，才看到在解析RPC请求的payload时填充的。
- 仅仅阅读源码，过一段时间就会忘记。所以还是要有产出的，比如整理一份文档，写一篇博文等等都可以加深映像，同时以后也可以回顾。
其实解bug和阅读源码有很多相通的地方。还是拿笔者的第一段工作经历来说。那时候客户报问题过来时，第一步就是尝试去复现，如果能复现，就大大增加解决问题的信心。也就是上面的第一点，运行起来。然后再在内网搜搜看有没有相关的文章。接着就去读源码，同时结合断点去查问题。问题解决后，也会写文章发布在内网。
以上是笔者阅读源码的一些总结，谈不上什么高大上的理论，也谈不上什么科学依据，仅仅是笔者的一点心得，希望能对读者有些启发。
