这样读源码，不牛X也难

程序员在工作过程中，会遇到很多需要阅读源码的场景，比如技术预研、选择技术框架、接手以前的项目、review他人的代码、维护老产品等等。可以说，阅读源代码是程序员的基本功，这项基本功是否扎实，会在很大程度上影响一个程序员在技术上的成长速度。

2014年写《Qt on Android核心编程》和《Qt Quick核心编程》时，很多内容都是通过分析Qt源码搞明白的。这阵子研究CEF和PPAPI，也主要靠研究源代码来搞明白用法。最近工作上要修改已有项目的一个子系统，也是得硬着头皮先读懂代码。

总之在开发工作这十来年中，读过太多源码了，从源代码中学习到太多东西了，如果不阅读源代码，真不知道自己能否成长起来。

写代码是从模仿开始的，提高也是从观摩别人的优秀设计和代码开始的。所以阅读源码至关重要，接下来咱从下列方面聊聊阅读源码的事儿。

目的

工具

知识准备

运行与开发环境

笔记

实用技巧

心理调试(散步在各个环节)

目的

当我们阅读面前的源码时，无非有以下几种目的：

纯粹学习

添加新功能

重构旧代码

修复他人的Bug

不同的目的会有不同的心情，会影响到工作的进展，像修复他人的Bug这种事情，类似于没被掰弯的男猿捏着鼻子给另外一个男人擦屁股，是很恶心的，很容易让人拒绝的。所以因这种目标而阅读源码，往往是欲拒还迎、欲说还休，效率较低。然而修复实际工作中帮别人修复Bug这种情形，十有八九你要遇到，无可逃避。所以，心理调试很重要。

为了学习去读源码，这是最愉快的最放松的。不过提醒一点，设定可检验的目标才会有收获，否则就会像走到大街上看见一美女擦肩而过那样，惊艳一下下，过后嘛关系嘛收获也没了。

其他的目的，重构旧代码、添加新功能，比帮别人擦沟子(陕西话，屁股)略强，因为他带有创造性，创造性的活动能给人带来强烈的愉悦，所以虽然这两种目的也有很多让人不爽的部分，不过想到我可以让一棵老树焕发青春，不爽也就慢慢弱下去了。

工具

工欲善其事必先利其器，这是亘古不变的道理。要很好的完成阅读源码的任务，我们大概需要下列这些工具：

SourceInsight，最好的源码浏览工具，它能维护符号库，动态显示上下文，还能绘制调用关系图，最好的，没有之一

纸质笔记本，随时记录心得和疑惑，随时绘制各种图(类图、时序图、框图)，比UML工具快，也比Visio快

中性笔

记事本、Notepad++、有道云笔记、为知笔记等，记录阅读源码过程中的关键点、心得体会、分析过程

Visio，用于绘制简单的框图，表述源码的模块划分、层次结构等

StartUML，用于最后绘制类图、时序图等，方便交流

扫描全能王(CamScanner)，一款可以通过拍照达到扫描效果的App，可以用它扫描你在纸质笔记本上写下的文字，绘制的框图，分享给其他人，如果你懒得用软件绘制图标，那手绘之后扫描成电子档就最适合你了

知识准备

前戏很重要，准备好了后面水到渠成快感不断，否则就会频频受挫直感道阻且长。

业务基础，每一份有实际意义的源码都离不开业务，必须先对业务有概念

技术基础，这个源码用什么语言，什么框架，什么第三方模块，都需要先有所了解

文档，尽量找到业务、需求、概要、详细等文档，帮助会很大，然而，我们经常面临的情况是，只有源码，只有源码，只有源码，片言只字的文档也无，所以只好坚信——源码是最好的文档。这个心理门槛儿其实也容易过，你就想像着源码只是神仙姐姐的画像，看再多画像也不抵当面一眼效果强大——要么摧毁三观要么魂牵梦萦

人，搞明白哪个程序员维护过这份代码，方便后面不懂时请教，有时人家点一下顶你自己瞎琢磨一天

运行与开发环境

配置好开发环境，目的是为了调试，对有些程序员来讲，调试是弄明白软件内部机理的最好方法，按着F5、F10、F11、F9，一切都搞定了

配置好运行环境，为使用软件、体验软件做准备，从用户角度，从外面看看软件到底是怎么回事，便于揣摩内部逻辑

笔记

在阅读源码的过程中，做笔记是必须的。我有这样的体会，因为代码不是自己写的，很难很快在脑子里刻下印记，经常是看着这里忘了那里，早上觉得弄懂了数据流向，中午吃个饭就忘了。所以，笔记就显得尤为重要。

找到适合你的记录方式，小本本、软件皆可。用软件(Notepad++、有道笔记、为知笔记等)来记录有个坏处——必须切换屏幕，会在形式上中断代码阅读过程。所以我经常在紧张得不能中断时随手用笔写些断句残章在本子上，告一段落时梳理下用软件再记录。

尽可能详细的记录，但不必看到什么记录什么，要间隔性的记录，比如弄明白了某个子模块的逻辑、某个类的作用、某些函数的调用关系时再记录，否则记录这个动作本身会打断思考

每天工作结束，记录进度(弄明白的部分)，记录疑问，记录第二天要弄明白什么东西，这样你的工作状态就入栈了，第二天来了很容易出栈，快速进入工作状态

记录看到的优秀设计，提高审美，见贤思齐，自我成长

沧海遗珠

我在漫长的读码生涯里积攒了一些的经验，算是碎碎念，供参考：

理清某一业务如何映射在代码执行流程上的，这点很关键。

理清不同模块间的业务关系，代码调用关系，很关键

调试是弄明白代码调用流程的最快方式，之一

找出关键代码(代表实际对象的类、衔接不同模块的类、代表业务关键节点的类)

分析日志可以帮助分析代码执行流程和业务流程

先用已有的可运行软件，体验业务，琢磨你点这里一下点那里一下代码可能是怎么做出反应的

阅读应该围绕目的，把实现目标放在第一位，比如修改Bug，如果有期限，在最后日期前搞定是第一要务，然后有时间就继续读源码或改进Bug修复方案，力求没有副作用和后遗症，再有时间就修修别人留下的破窗户(你也可以顺带鄙视下前任维护者)

千万次的问，还记得前面说要弄明白谁维护过你要读的代码吧，别不好意思，问吧，问吧，问吧

对着设计文档、接口文档或测试用例看代码

心理调试，勿畏难，别放弃。我有时看代码，看两天也不知道看了个甚，一头雾水两眼发花是常有的事儿，有时真是觉得搞不定了，然而，这要么是你基础知识没准备好，要么是你找错了入口，要知道，任何一份代码，都有一条隐形的线串着，耐心点，总会找到。这样不行就那样，多换换角度，多换换方法，读不行，就调试，调试不行，就运行，运行不行，就研究日志，都不行，我靠，while(!i.isDead())i.analyzeCode()，跟Y死磕!总之，你不放弃自己，就没人能放弃你!

给自己设置小奖励，弄明白某个逻辑或某个模块的代码后奖励自己休息一下，5~10分钟，走出办公室转转，或者干脆在网上瞎逛一下，浏览自己喜欢的网站

读不懂才要读，想不明白才要想，这是进步和成长的开始。那些阻挡你的蹂躏你的而杀又不死你的，终将帮助你成长让你变得更强大。