track image
如何阅读一份代码?

如何阅读一份代码?

陈天陈天

上文谈到了像读书一样阅读源码的重要性,今天谈谈如何阅读一份代码。我所谓的一份代码,其范围可能从几千行到数万行,有时甚至可多达数十万行。这些代码作为一个有机体,共同完成某些重要的功能。比如说几个著名的 full fledged web framework,祖师爷 rails,师叔 django 和小师妹 phoenix:

三者对比很有意思 - rails / django 的代码数都在 200k 上下,而 phoenix 小了整整一个数量级,仅仅在 20k 左右。实现大致相同的功能,语言的表现力难道差距如此之大?这解释不通。实际上 phoenix 实现的功能,和 rails 对标,应该是 actionpack/actionview 两者加起来约 80k 的代码。而 rails 内嵌的 activemodel/activerecord 应该对标 elixir 的 ecto,恰巧又是 80k 比 20k。这种差异反映了语言表现力的差异,同时也体现了框架的成熟度的区别。

几十 k 体量的代码,就像一本不薄不厚的书,读着既不算太过吃力,也不至于读完意犹未尽。

有些巨型的代码库,如 linux kernel,块头堪比『战争与和平』,代码的规模宏伟到令人绝望,大大超过了我们能够阅读理解的范围。其结果是我们每每下定决心阅读,投入的巨大的精力,却像往一池湖水里投个石子,虽掀起一丝涟漪,但湖面很快就归于平静。

读不下来,我们也不要太绝望,可以分而治之,先定个小目标,每次读一部分,比如 scheduler(20k)或者 memory management(80k)。

在选定合理的代码规模和要阅读的源码后,我们就可以清开书桌,摆上 mac,准备好笔墨纸砚,留出至少一个小时到半天时间,开始徜徉在代码的海洋。

由于上一篇文章(为什么我们要阅读源码?)从头至尾将阅读书籍和阅读代码进行对比,很多人会不禁联想本文会否和『如何阅读一本书』进行类比,提供同样的思路:基础阅读,检视阅读,分析阅读,对比阅读。不错,这些读书的方法对读代码非常有参考价值,比如说检视阅读,我们读大型代码项目,也是类似的思路:

  • 我们会读根目录下的 readme,或者任何看上去撩拨着你让你戳它的文件。这就跟书本的「序」一样,能够帮你更进一步了解这份代码的意图;

  • 接下里我们目光需要聚焦在代码的目录结构,和每个源码的文件名。他们就像书本的目录页。如果每个目录下有 readme,也可快速阅读之。很多语言和框架,有约定俗成的目录结构(Convention by Contract),因此,通过目录我们就可以快速知道哪些是可以略过的部分,比如 django 的 management/commands 目录,elixir 的 mix/tasks 目录,这些目录,承载着支线剧情,需要的时候,或者闲得无聊时再读也不迟;

  • 然后我们开始从入口梳理主线。不同语言和框架的主线不太一样,比如 C 的入口是 main(),erlang/elixir otp app 的入口是 app:start,nodejs 往往是根目录下的 index.js,等等。一般而言,application 的主线比较清晰,一路下来,会走到一个 mainloop,而 framework 的主线会晦涩一些,因为 framework 往往是 application 抽象出来的部分。

但本文不会过多这样去对比 —— 大家真有兴趣,何不亲自读读那本书(读过的请带着读代码的角度再读一遍)呢?毕竟,它更加完备,更加系统。

我想通过另一个角度 —— 阅读的场景来谈谈如何阅读。谈到场景,很多人会联想到一本著名的书:Linux 内核场景分析。该书的作者显然把握了阅读代码的实质:循着一条线索,进行端到端的一个自成体系的内容的阅读。不同场景下,我们已知的信息,未知的信息,通过阅读想要达到的目标是不一样的,显然,方法也不尽相同。这就和读书一样:想要让自己明智,读史;想要让自己灵秀,读诗;想要让自己周密,研习数学;想要让自己深刻,攻读哲学等等。

接下来,本文就从若干阅读代码的场景开始,讨论个人的读代码的一点微不足道的心得。

场景一:为了破案而阅读代码

这是我们最主要的阅读代码的场景。工作中,免不了用各种各样的开源系统(别人的代码)。使用的过程中,你会遇到各种奇葩的问题,这些问题可能源于对文档的理解不够,或者从网上抄一个已有的,并不完全适合你使用场景的样例,或者是真的撞上了八阿哥。在想方设法解决的过程中,如果同事帮不上忙,google/stackoverflow 不够给力,论坛上各种「急,在线等」也无人理会,你会开始抓狂,仿佛被摄魂怪缠上了一般,生活中的各种美好,希望,都开始离你远去。

这时,你不得不像 CSI 中的警探一样,顺着一点蛛丝马迹,开始剖析代码,试图从迷雾中还原真相。你会抛开一切纷扰和杂音,集中精力,带着线索,循着问题,读且只读和解决问题直接相关的代码。这种状态,我管它叫「猎手模式」—— 我们有如非洲草原上追逐离群斑马的狮子,把身上燃起的小宇宙集中于一点,眼睛紧盯猎物奔走的方向,腿如疾风,势如闪电,心中不断地盘算着雷霆一击究竟用锁喉,打脸抑或拉后腿胜算更大。道路上的石子划了脚,痛;飞奔时撞上了幺蛾子,烦,但这都不是事儿。就算远远的乞力马扎罗山上难得地挂上了两道彩虹,煞是美丽,自拍后发朋友圈定能破百赞,你也无暇顾及这些并不重要的细节。

专注,集中力量攻击且仅攻击一点是这样场景下阅读代码的主要方式。

拿我遇到的 nginx cache 的问题来举个栗子。一年前,当我接手 Tubi TV 的性能较低且很难维护的 API 系统后,虽打定主意日后重写,但摆在面前的,刻不容缓的问题是提高性能。应用层可以施展的空间不大(数据已经在 redis 里),所以只能在 web 层打主意。在 HAProxy 和 nginx cache 之间,我选择了后者, 因为 nginx 已经在当时的生产环境下大量使用。我虽然没用过 nginx cache,但启用 nginx cache 并不是难事,照着文档设置好 cache 的路径和大小等参数后,在需要使用 cache 的 location 下,设置 cache key 并使能即可,我本地的简单的测试运行正常。然而,在生产环境中,本该命中的请求却一直处在 miss 的状态。我一筹莫展,尝试了网上搜到的各种方案无果。最终,我决定自己编译一个打开 DEBUG 开关的 nginx 版本(--with-debug),记录更多的日志,然后对着源码找问题。

nginx cache 及 upstream 里和 cache 相关的代码量并不算多,几千行,我快速过了一下,然后就着日志上的内容寻找相关的处理流程,并在几个大的 bailout 分支猜想可能出现的情景。由于 nginx debug log 还是不够详细到满足我的需求,我在这些没有被顾及到的分支上各自加了调试代码,重新编译,运行。

这个过程中,「猜」起到了很大的作用。我记得本科时的数学老师 —— 一个可爱的小老头 —— 点名提问对方答不上来时,常常挂在嘴边的口头禅是:你猜一下嘛。他总说连蒙带猜也是解题的一种思路,伟大的数学家同时也是伟大的猜想家。

我们读代码时,猜文件名,函数名,变量名的意图,猜某个分支的意图,猜某段代码的意图,最终结合运行的结果,打印出来的调试信息来印证我们的猜测。这是读者和作者间有趣的猫鼠游戏。读得越多,猜得越多,印证得越多,形成一个有效的 feedback loop(read - guess - verify),你下次猜测成功的几率就越大。

最终,问题被我定位出来 —— 它是两三处 configuration 未正确配置的问题。stackoverflow 上的答案是部分正确的,它解决了绝大多数人的问题 —— 没有 ignore cache control 相关的 header 几乎被每个初次使用者忽略了,它也是我的配置问题之一。但之所以这个答案没能解决我的问题,是因为我们生产环境中的 nginx 有个不起眼的配置 disable 了 proxy buffer,从而导致 nginx 直接跳过 cache。

从以上的过程中,我们抽象一下,看看为了破案而阅读代码要注意什么:

  1. 带着线索,从一堆代码中找出和问题相关的代码。nginx cache 的例子中,线索是 proxy 的 upstream,cache 总不能命中,所以出问题的代码和 cache,proxy,upstream 有关。源码目录里一翻,就能挑出需要看的文件。由于问题在 cache 上,在挑出的文件中,具体看 cache 相关的函数名,宏名,以及代码。

  2. 专注阅读挑出来的内容,忽略不相干的噪音。在阅读的过程中,着力寻找潜在的触发问题的路径,然后动用「我猜我猜我猜猜猜」大法,加调试信息。

  3. 编译运行修改过的代码,复现问题,分析调试信息,然后,bingo,恭喜你答对了!请进入第 5 步。

  4. 没答对,请回第 1 步。别急,这不是高考,在老板忍无可忍炒你鱿鱼之前,你一直拥有再来一瓶的机会。

还有个关键的第 5 步,我单拎出来说。很多时候我们轮回数次,终于在第三步 bingo 后快乐地像是刚刚 K.O. 了对手的春丽,夹着腿跳将起来,左右手在空中一齐比划着二,得意忘形,以至于忘记了执行第 5 步。

喜悦是短暂的,记忆也是短暂的。整个过程你的目标是如此清晰,执行力无比强大,为达到目的「不择手段」。三天后老板问你,小程啊,你很棒啊。你用了什么手段征服了这个无比难缠的八阿哥?这时你拼命追忆,却像拿筛子盛水,忙乱半天一无所获。你开始怀疑人生:三天前的我和现在的我究竟是不是一个人?

所以关键的第 5 步是:复盘。解决问题后,别着急接受同事们的致谢和女(男)神的秋波。趁着那坨记忆还热气腾腾,抄起 evernote(或者 xxx),把整个过程用最简洁的方式记录下来 —— 关键代码,关键路径,到达终点的整个猜测过程,以及那些日志验证了猜测是对的,哪些日志验证了猜测走不通(恭喜你 —— console 或者 terminal 在这个时候应该还没关),总之,你在不择手段的过程中用过的一切手段,都应该像记流水账一样记录下来。最后分析总结:

  • 这个问题的 root cause 是什么?触发它的代码的流程是什么?

  • 在读代码的过程中,哪些地方我猜对了,哪些没猜对?

  • 有功夫的话,代码的哪个部分是值得细细品读把玩的?

  • 下次再出现类似的问题,我该怎么更快地从源码中定位出问题?

在这种「破案」般阅读代码的历程中,如果没有复盘,你 70% 的功夫白费了 —— 你花了不少时间,读了不少代码,除了一个好的结果外,并无太大的收获。可惜的是,绝大多数工作场景,我们都略过了这步。我自己也是(深刻检讨中)。写这个章节时,我搜了搜我的 evernote,翻了翻我的邮件,除了去年初有封邮件只言片语介绍了我使能了 nginx cache 外,再无其他记录。好在我当时解决完问题顺便又读了些 nginx cache 的代码,有些许印象,所以还能把它搬出来做例子。

复盘帮你把这样的信息沉淀下来,让你有机会回顾,进而组织和固化成上篇文章中所说的知识。这样的内容累积多了,慢慢你的头上就会顶起一个光环,光环上傲娇地写着:砖家。

场景二:为了明理而阅读代码

场景一所述的读代码方法是被动的,为了对付问题而读,是大部分人精进代码的唯一途径。这就好比英雄无敌里你就做个守成之主,收收矿,屯屯兵,从不主动招惹野怪,只等着敌人来进攻。这样三个月下来,就打了几仗,稳则稳矣,无奈经验值增长太慢。

要想涨快点怎么办?主动出击啊!计算机领域的很多算法,基础知识,理论,在看过书,读过文章后我们都似懂非懂,这时,阅读代码就是最快地巩固和加深理解的方式:

  • 算法:bloom filter 究竟怎么实现的?怎么样把 bandit 算法在自己的系统上做简单的推荐?ossip 协议实际的生产环境的代码是什么样子的?Linux kernel 如何实现 O(1) scheduler?

  • 基础知识:一个完整的涵盖 HTTP 1.1 协议的 REST API framework 如何实现?一个 packet 从 OS 的 driver 是如何一路送上 application 的?什么是 zero copy?Linux kernel 如何实现 zero copy?

  • 理论:啥是 IoC / DI / Pub Sub?各种 framework 都是咋实现这些设计模式的?supervisor 这个 behavior 背后的实现是如何的?

这个过程是一个正反馈,是马太效应累积地过程。你读的书多,你脑子里的知识点就多,疑问同样也多。这些疑问促使你读相关的代码去印证和解惑,代码读多了,又感觉理论知识欠缺,于是周而复始,不断学习下去。反之,书读得少,你脑子里都没存几个问号,也就无所谓读代码去求证了。

以 REST API framework 为例 —— 两年前我还在 Juniper 做 web security 时,需要做一个坚实的 API system。我们知道做网络的,干起事来要比做互联网严谨得多(所以也慢得多),于是我花了好些时间读了 RFC 2616 及其后续的修订(7230-7235)。然后就是对 API framework 进行选型,找个合适的。当时我正好在研究 clojure,便拿了 liberator 来看。Liberator 受 erlang 下的 webmachine 启发,用简单的 macro 把 decision tree 实现得很优雅。后来我又扫了下 webmachine 的 decision tree,pattern matching + 递归,非常漂亮。可惜当时我在的团队思想比较僵化,眼里只容得下 python。无奈我退而求其次,选用了 eve,一个 python 下的 rest API framework。eve 的代码质量中规中矩,平铺直叙,明显像是你我写出的代码的模样。

详细讲讲我读 webmachine 的过程。我读 webmachine,完全是 liberator 的引荐,liberator 的作者说其 decision tree 来自于 webmachine,并附了图。这时的我就像刚练了李小龙的截拳道,听闻这功夫源自咏春,一下子就心痒痒欲探探咏春的虚实了。

webmachine 的代码很短,只有 4700 行。循着文件名很快就能找到 webmachine_decision_core.erl,这是要阅读的主体内容,约 800 行。这 800 行代码,我们可以将其分成三个部分:头 150 行,decision tree 的架子;中间 300 多行,是具体的一个个 decision 的实现;剩下的两百行,是辅助函数。

每个 decision 的流转见 下图

这里 atom 的命名完全跟着图走,比方说 v3b13 这个 atom,含义是 v3 版本的图,b 列 13 行的 decision node。这是第一个 decision,如果 service available,则整个 flow 继续往下走,否则返回 503 service unavailable。

明白了这一点,按图索骥,代码的执行流程非常好懂。接下来的事情就很简单了 —— 顺着流程一个一个看 decision node 的代码,RFC 2616 变得鲜活起来,在你眼前跳动。我们再看一个例子:precondition check,是 v3g11:

这段代码从 http header 里读出 if-match header 里的 etags 列表,然后通过 resource_call 调用 generate_etag,来生成 etag,和 etags 里的任意一项匹配,如果匹配,跳转到 v3h10,否则 412 preconditional failed。webmachine 怎么知道如何生成 etag 呢?这便是 framework 的功力了,它抽取并实现协议的公共的部分,而将业务逻辑延递给使用 framework 的 application。换句话说,generate_etag 是 application 要实现的 callback。这便是 IoC。

这个代码解释到这里,明白 HTTP 协议中 etag 作用的人,或者对 concurrency control 方案清楚的人自然一目了然;但我相信不少人会很难理解它的应用场景。再进一步解释一下:比如小明和小红是程序人生的两个管理员,他们通过 API 同时从数据库中获取到程序人生的基本信息(名称,描述等) v1。小明把程序人生的名字改成了「序员人生」,调用 PUT API 成功修改数据为 v2。小红也同时修改这个数据,但她还是使用原有的 v1 的数据进行修改,结果提交时把小明的修改覆盖了。这是个 concurrency control 的经典场景 —— 令人谈虎色变的 race condition。怎么办(想想你平时怎么处理)?HTTP 协议的处理办法是:小明和小红拿数据的时候,同时拿到一个「版本号」(你就想象成数据的 sha1),这里管它叫 etag。小明更改后,数据的 etag 变了,小红拿旧的 etag 提交时,服务器一检查当前的 etag,不匹配,于是便 412 了。这是一个简化了的 optimistic lock。

拉拉杂杂说这么多,只想说明一件事:能够读懂代码,和理解代码的应用场景是两码事。但是当你真正理解之后,你的代码功力就大涨。日后做并发环境下的共享对象更新,你脑袋里会闪个问号:吓,这里可不可以不用 lock(pessimistic lock),而是考虑类似 If-Match 的机制呢?

言归正传。之前的整个过程,我都在理解作者的意图。心满意足后,我一般会问问:

  • 这代码有可以优化的地方么?

  • 有潜在的安全漏洞么?

  • 是否有未处理的状态或者异常?

这短短五行的代码,lists:member 是个 O(N) 的操作。O(N) 的操作都该引起我们的注意。我们知道,membership check 用 set 而非 list,效果更佳。从安全的角度讲,split 出来的 ETags 是个薄弱环节。攻击者可以构造足够大且复杂的 if-match 头,来扯慢单个 request 的处理,从而达到更好的 DoS 效果。至于未处理的状态,这里可以放心 —— 有了上文中所示的如此详尽的流程图(状态机),这代码不会有大的问题。

OK,这栗子炒的时间够长了,打住。我们对比一下三个 API framework 的代码量:liberator 1.2k,webmachine 5k,eve 12k。读 liberator 的感觉像是楚辞,优美但晦涩;读 webmachine 的感觉像是数学教材,满纸都是递归推导;读 eve 的感觉像是读本科生的论文,完成了功能而已,读完没啥印象,倒是有些反面教材:整个 framework 写得太死,一些本不该 framework 做的决策被做了,以至于要满足我们的某些需求,最终只能通过 fork 它改 framework 的代码来完成,而这是 framework 的大忌(我们当时用的是 0.4,写本文时是 0.7)。

我们总结一下 —— 为了明理而阅读代码的方法并不太难:

  1. 先使用前面所述的检视阅读法把整个代码过一遍,找到值得阅读的核心代码。

  2. 粗读这部分代码,将其内容进一步 breakdown。手边准备好笔和纸(或者其他趁手的工具),随时记录。记录最好的方式是图表。这个阶段的记录不建议用软件工具(除非有用着特别舒服的,能够人件合一的)。

  3. 精读这部分代码,结合你已有的知识,理解这个代码所需要的资料,猜测和还原代码中某种事件,消息,或者某个流程发生的场景。把猜测记录下来。这时,如果遇到外围的代码(调用了外部的函数),只要对理解不产生障碍,可以先放一下,把整个过程完整而详细地捋一遍再说。这个过程一定要多问问题,把「我以为我懂了但实际没懂」的情形尽可能减少。

  4. 用检视阅读法粗度剩下的代码,如果找到其他值得精读的代码,跳至 2。

  5. 使用对比阅读(或者说,主题阅读)方式,把类似功能的 repo 都扫一遍。尝试着用自己的语言消化不同作者的实现,关注其实现的差异,并试图评判这种差异。

  6. 用软件将手稿电子化,便于将来回顾。文字可以直接上笔记本工具(甚至可以尝试 gitbook),图表如果买不起 visio,omniGraffle 这样的工具,可以用 plantuml。使用方法参考我的文章:那些年,我追过的绘图工具

最后一步是个非常耗时的过程,除非你有惊人的毅力,或者好为人师,要把你的心得分享出去,否则,做的动力不大。当然,在这个场景下,我们是悠然自得地读代码,没有客户老板拿着鞭子在后面抽,所以读懂之后记忆会非常深刻,即便没有电子文档留存,回到代码翻一翻,记忆就能还原了。

再次反省:我第 6 步也做得不好,有些手稿,如果不拍成照片,就永远的丢失了。

(我对 app master 的初始化的简单总结)

这样的阅读做得越多,真正搞明白的理论,知识和算法越多,你就越是不可替代的大拿。有时候,其实我们只要认认真真花上几个月,搞明白某大型项目,基本就是人中龙凤了。

场景三:为了能级跃迁而阅读代码

中学物理告诉我们:原子在光的辐射下,吸收光子,可以从低能状态跳跃到高能状态,电子的轨道,或者说能级(energy level)会发生跃迁。这和哲学上常常提到的量变到质变异曲同工。作为一个程序员,你的发展历程也是这么一个过程:在工作中缓慢爬坡,到达一个平台便停滞不前,似乎股票走势上的箱体整理。然后突然有一段时间,不知道受了什么刺激(比如说野战打出了龙王神力,或者说读了程序人生*_*),突然连拉几个涨停上了另一个平台。

打破平台期,成就能级跃迁,你需要吸收合适的「光子」。这光子可以是一个开天辟地的项目(比如说 Google 的 Google Map,docker 的 docker,阿里的淘宝等),可是这样的机会并非总能被你我赶上,大多数人都是在日复一日地做些并不起眼的,只能缓缓升级的小活 —— 就像一个七级的英雄带着一群大雕,却只能天天怼大耳怪地狱恶犬狮鹫之流的野兵。这时候,与其默默沉沦,不若学庄子口中的北冥之鱼那样,沉潜浮动,积蓄能量,等待下一次抟扶摇而上九万里。

这种积蓄能量为跃迁准备的一种方式是读代码。读什么?读那些基础地不能再基础,你认为自己一辈子都不会去写的那些代码。比如 linux kernel,比如 OTP。这种读法,你不知何时能够完成,所以,要有足够的耐心和时间。检视阅读 + 主题阅读 + 思维导图是经常用到的方法。下图是 OTP 的源码我在检视阅读后,圈定的要逐渐阅读的部分,加粗的是我已经完成粗读的部分。

OTP 的代码不算少,但是耦合度非常低,其实最终是拆分成若干个场景二去阅读。我们看其代码总量:

1.4m loc,近乎恐怖。但除去 example 和一些无关的辅助代码后:

930k,小了约 45%。而我圈定的第一批阅读的代码,只有区区 130k 而已,不消两天可以粗读,顶多半年,可以精读。如此这般,半年后,你的水平必然非当日的吴下阿蒙了。

需要指出的是,这种阅读有时会让人非常沮丧,因为你会遇见非常非常之多的 knowledge gap,从而不得不翻书查资料弥补这些你缺失的知识点,拉慢了整个阅读理解的步伐 —— 有时甚至数日毫无进展,让你心中被激发出来的那口气开始渐渐衰竭。这时候,稳住!这些 knowledge gap 是上天馈赠的礼物,是你弥补 you don't know what you don't know 的绝佳机会。慢慢来,take it easy,享受获取额外知识的喜悦。

这样数年下来不断充实自己,你写代码做项目时,离余光中老师描绘的,令人神往的李白的「绣口一吐,就半个盛唐」的状态不远矣!

分享一个小故事,结束这篇文章:

在 Juniper 的早年,我在写 netscreen data plane 代码的总结(就是我在其他文章中提到过的被公司同事戏谑为『葵花宝典』的那份内部文档)时,因为想更加弄清楚 IPSec phase 1 SA 建立的过程,潜进了 IKE 的后花园。彼时我对 IKEv2 不甚了解,读了很多资料,然后才开始看代码。代码我看得懵懵懂懂,catcher,thrower 等奇奇怪怪的表述让我如同黄帝陷入了蚩尤的迷雾中不得方向。后来在同事的提醒下,我才知道那一堆术语都源自棒球,在 wikipedia 上搞懂了这些棒球术语的意思后,那些代码开始变得可爱起来。

几年以后,我第一次读了『如何阅读一本书』,作者用了一大段文字通过棒球的捕手的技巧来类比阅读的技巧,用捕手和投手的关系来类比读者和作者的关系,读者读者,我不禁回到了十多年前那个满是阳光的午后:我坐在宽敞的办公桌前,使用桌上的无盘 SunRay 工作站接入了一台以格林童话 Gretel and Hansel 命名的 solaris 服务器上,然后使用 vim 打开了 IKE 的建立连接,六次(不知道记忆是否还对)握手的代码,咂着香浓的咖啡,开始观看一场精彩纷呈的棒球比赛。。。

「想请我喝咖啡请随意 :)」
10 人赞赏
Crabit
杨哲沣
xiyu ding
Allen
晓天
邵严民
等人赞同
Reo Lei
文章被以下专栏收录
42 条评论
推荐阅读