笔者之前的博文都偏向于源码分析,因为平时,笔者喜欢钻研技术,阅读项目的源码以窥其内部原理。阅读源码,是工作中不可缺少的能力,同时,也是技术积累的重要手段。阅读源码,一方面可以加深对所读项目的理解,另一方面,也能从中学习到一些技术,提升自己的技术能力。
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和阅读源码有很多相通的地方。还是拿笔者的第一段工作经历来说。那时候客户报问题过来时,第一步就是尝试去复现,如果能复现,就大大增加解决问题的信心。也就是上面的第一点,运行起来。然后再在内网搜搜看有没有相关的文章。接着就去读源码,同时结合断点去查问题。问题解决后,也会写文章发布在内网。
以上是笔者阅读源码的一些总结,谈不上什么高大上的理论,也谈不上什么科学依据,仅仅是笔者的一点心得,希望能对读者有些启发。