怎样高效的阅读源代码

(原文首次写于新浪博客 2011年5月份)

5.1放假三天，大多数同事都没来加班。我来了，因为我们的客户需要我们的设备支持命令行的配置，之前我们给他们做的web形式的配置和显示，他们嫌太傻瓜了，不够专业。我靠，给他们提供人性化的配置界面，他们还嫌傻，非得花费脑细胞去记什么命令，还让我们再额外消耗脑细胞去实现这些命令，真TMD的脑残！

不过，给钱的是大爷，客户就是我们的上帝。咱就是干活的。好，入正题。

4月29日上午11点，我来到公司，我今天的任务就是完善命令行的配置（朱姐已经完成了各个命令的基本实现）。但我绝不是把活干完就心满意足的人，我要从头到尾把整个命令行的框架和具体实现（至少是我关心的模式切换和命令调用这些实现）都弄明白才算罢休。于是我开始阅读命令行源码。

以前我有过经验，如果你刚开始就对代码理解的不深刻，那么到后面你就会越来越不深刻，以致很快就会烦躁起来，最后一塌糊涂。所以我无论什么时候，我阅读代码总是一步一个脚印，稳扎稳打，逐行逐句的进行阅读，凡是碰到的每一个全局变量，每一个函数，我都会深入进行，全部看完。到下午4点钟的时候，我读到了vty_read这个函数，发现里面的一个for循环里，有很多if else语句，而且这个for循环很长，我感觉要把这个函数完全理解，一个晚上的时间也未必真的够用，因为它牵涉了很多外部变量。此时我开始心灰意冷。但我的倔脾气并没有妥协，我继续逐行逐句地看。直至凌晨3点的时候，我才大致把这个函数看完。只是粗略的看完，并没有像刚开始那样仔细，因为实在是有心无力，外部变量很多，而且都不知道是干什么的。

此刻我有些困了，但我的任务还没有完成，我的真正任务是完善命令行，不是把命令行的源码从头到尾读一遍。之所以想读源码，只不过想更深层次的了解它的整个运行机制。但现在我该回去睡觉了，我的既定任务却一点也没完成。

我不再读源码，取而代之，我开始在源码的几个函数里打调试信息，以追踪它的执行过程。忙活忙活，两个小时又过去了，执行过程也大致了解了一下。但我的几个命令行bug还是没有解决。我困了，此时已是凌晨6点钟了，我开始回家。

走在回家的路上，我非常不甘心，我有点难过，一个问题都没解决，愿望也没有实现。

我开始意识到我的方法不对路，我走偏了剑。我应该先解决问题，带着问题去阅读源码。。。。

待续……

接着上次的写。上次写到没完成任务（命令行bug未解决），也没完成心愿（把命令行相关源码看完，理清其架构设计，并理解其执行原理），五一结束后的第一天，我又继续理解命令行架构和执行原理，不过我改变了策略，不是一味地投入到阅读源码中，而是用gdb运行程序，设置断点，跟踪程序的执行流程。一下午时间过去，我对命令行的执行流程（调用了哪些函数）有了80%的了解，又结合执行流程，重点看了一些函数的内部实现，然后又用gdb跟踪程序的流程……

这样的效果很好，首先用gdb跟踪运行，了解了命令行的执行流程，然后结合自己的疑惑，重点看某些函数的内部实现，然后继续用gdb设置断点，跟踪运行，验证自己的想法。