以Linux内核源代码为例：
使用工具source insight
首先建立源代码工程，source insight会帮助你建立一个库
它能够帮助我们在看一段源码的时候，跟踪函数、变量的定义、声明、调用等情况
能够识别多种文件，基本上常见的都能识别
看源码的顺序，个人以为：
1）看源代码的目录结构，大致了解各个目录下都有些什么，可能是什么，有的源代码中
有readme或者其他文档可以告诉我们源代码的目录结构
这时候有两种不同的顺序看源码了：
第一种：
大致看一下Makefile，如果对make很熟的话，就可以知道源代码是如何编译的，可以知道程序的入口是什么
这里可能需要掌握一些gcc编译工具相关的知识，可以在gnu.org上找到manual文档，随时翻阅
然后，从程序的入口开始看起，看程序初始化了一些什么，最后是否进入一个主程序，主循环
再然后，可以分模块看了，可以根据初始化流程中的初始化顺序看各个模块，也可以根据主程序中用到的关键
模块开始看
第二种，与上面正好相反
首先看各个模块的实现，大致了解之后，看这些模块是如何被串起来运行的
基本上在看源代码的过程中，上面的一些方法可能会重复、反复，
从粗略到细致，逐步细化的看比较好
如果一上来就陷到代码细节中，会感觉比较郁闷
还有一种，就是带着问题看源代码
你对源代码的哪个部分感兴趣，那就专门看那个部分
比如想看Linux中的slab算法，那么就专门看slab.c等相关文件
这时候，要先看关键数据结构，如kmem_cache_s，slab_t等
围绕数据结构看：
1）数据结构什么时候会被实例化
2）实例化的数据结构是什么时候，如何被初始化的，从而可以了解slab算法的初始化过程
3）哪些接口会对数据结构进行操作，并导致数据结构中的关键数据项（或者你所关心的数据项）发生变化
从而可以了解slab的分配和回收，或者其他你所关心的算法细节
4）如果其他模块想使用slab，那么应该如何使用，这就需要寻找一个使用的实例
在上述过程中，source insight的追踪功能将会被使用的比较多
刚开始我也被阅读代码的问题所困扰，在公司接受一个换了4个开发团队，没有任何文档的代码。我阅读的经验是：
1.首先将代码编译，多运行几遍目标程序，了解业务流程。
2.自己编辑一个数据字典，不求完全和系统一样，以后的阅读过程中再改进。
3.从main.cpp（类似的项目，通常有一个主文件）开始阅读，注意全局变量，因为很稀烂的班子开发的代码里，会有很多全局变量。
4.用简单流程图和E-R图把代码里比较复杂的逻辑记录下来。