如何正确的阅读源代码？

写完「你也可以像 Prisma 一样渲染图像」之后，有读者提了这样一个问题：

我猜您平时应该有阅读开源项目的源码，好的开源软件或者框架，动辄数万行的源码，虽说是宝藏，但我看源码一直不得要领，投入时间不少但收获甚微，请教下：

您阅读源码的关注点一般有哪些?

您看源码有没有什么方法论呢，如何抓住重点下手?有时面对优秀的开源框架，想学习，我甚至都不知从哪看起。

关于这个问题，我说两句。

阅读优秀的源代码是软件工程师提高自己编程能力和学习开源框架的最佳手段之一。作为一名运动员，除了持续的刻意练习，还需要观摩大量对手的比赛视频。作为一名小说家，除了笔耕不辍，还需要阅读大量的其他作家的伟大作品。当然，观摩和阅读不是目的，是手段。路遥在创作《平凡的世界》之前读了大量的「名著」，然后，他把所有尊敬的作家都安放在远方历史为他们准备的「先圣词」中，让他们各自光芒四射，照耀大地，然后开始创作百万巨著《平凡的世界》。照耀你的世界的光芒，应该是自己发出的。

程序员亦是如此。在编程的路上，有无数的大师写出了伟大的代码和软件，去学习他们的编程技巧和技术风格，取其精华，去其糟粕，最后完成自己的作品。2005年左右我有幸参与了一个类似 CORBA 的分布式应用系统的开发，我在那段时间差不多通读了这个项目的早期代码，其整体架构规划和代码设计的精巧程度让人叹为观止(代码的编写者是早期的 CORBA 规范制定者)。这个经历对我后来的编程之路产生了深远的影响。

与编程一样，阅读别人的源代码永远不是一件轻松的事，或者说，是一件困难的事情，需要持续的投入，阅读、研究、把玩、实践。很多人觉得拿到了源代码就像买了本书一样，放到书柜上，立刻就产生了一种学会了的错觉(我就是这样，微笑)，但真正实践起来才会体验到强烈的挫败感。大部分情况下，读不下去，不是方法不好，而是投入度不够。

阅读源代码，一定要找到好的开源项目。什么是好的项目?口碑好且应用广泛的项目就是好项目，比如 Docker、Spring、OpenResty，都是非常好的阅读素材。另外，完善的文档和足够的 test case 覆盖率，都是衡量一个开源项目是否优秀的标准。很多人说，代码即文档，好的代码本身就是自解释的。但是，对于规模宏大的开源软件来说，没有文档是不可想象的。所以在阅读源代码之前，一定要读文档。尽管读了文档之后，你可能不知道代码的技术细节，但至少可以了解项目的轮廓。结合开源项目的代码目录，差不多可以绘制出一个粗粒度的整体架构图，类似这样的：

然后为每个目录(或模块)做记录和标识，逐一阅读，或者直接去读你最感兴趣的部分。

我读源代码喜欢自顶向下的方式，先把整体脉络理清楚，然后按照模块去阅读代码，把类和类、函数和函数之间的调用关系记录下来，如果可以进行逆向工程，用类似 Intelli IDEA 这样的工具把代码之间的调用关系用 Diagrams 展现出来，阅读会更加直观一些，不同的语言有不同的工具可以选择。

另外，阅读 test case 同样能帮助你理解作者的代码设计意图。正常情况下，测试用例都是从文档和设计衍生出来的，而不是完成了代码再写 test case。阅读测试用例，可以让你更清晰的知道对应的类和函数想要做什么事情。

阅读源代码需要顺手的工具，我自己喜欢用 Vim，配合 NERDTree、CtrlP、ctags、taglist 等插件，Vim 可以成为一款优秀的代码浏览工具，而且非常轻量级。你可以在终端里用命令迅速打开、关闭、查找和索引程序，并进行有效的关联跳转(静态代码)。如果你不习惯，也可以用 Sublime Text，Atom 等工具。当然，如果你要进行调试和跟踪，那最好使用相关程序栈的 IDE 工具，比如 Eclipse、Jet Brain 系列工具，Xcode 等等，这样你可以在 debug 状态跟踪所有的函数调用和变量参数在执行时间线上的变化。

如果你喜欢 Vim，可以看下这篇「Vim 8.0，姗姗来迟」。

重复一句，工具和方法永远不是最重要的，去读，并在遇到困难的时候，看不明白的时候，咬牙坚持下去，抽丝剥茧，逐个击破。最终，你会在冰冷黑暗的二进制世界里面看到一张地图，找到一座灯塔，然后去解释和还原这个底层世界里每一个细微方面的语义，重建出高层次的抽象概念和关系。

最后推荐两本书，《Docker 源码分析》和《Go 语言学习笔记》，这两本书，都是关于 Go 语言的，可以说是源代码阅读的典范，有兴趣可以找来读读。

作者：佚名

来源：51CTO