我先说下自己的经历吧。
我比较完整的读过的有wordpress，ttserver（tokyotyrant+tokyocabinet），memcached，redis的源码，最近正在系统地读nginx的源码。

相信重复的力量
读源码过程中最深的一点体会就是，重复重复再重复。当年读ttserver源码是刚入行，本来对C就不熟，ttserver里有很多比较奇怪的代码习惯，于是硬着头皮vim一行一行一遍一遍地看，有些不懂的地方，看十来遍，还真就懂了，可能算是量变引发质变吧。

从数据结构入手，先想后读
然后后来我学聪明了一点，不再从main函数一行一行的开始，学着先读 .h 文件，了解数据结构，结合能找着的文档，脑补作者的思路，在这个基础上再去读源码，看自己和作者想的有什么不一样，经常能发现自己错误或者不周全的地方，偶尔也能窃喜和大师们的不谋而合。

善用工具
再后来发现原来有ctags这类东西，如有神助，加上这时对C语言的基本写法有了一些了解，读码效率顿时提升。今年下半年在lua和nginx中选了先读nginx代码，目前结合一些工具做记录，也颇有成效。

理论与实践结合
当然，我读过的所有源码，都不是为了读而读，基本都是我工作中经常会用到，会面对的一些东西。所以这里有一点也很重要，建议最好先了解你这个东西的功用，再去读源码，否则真的很难读懂。最最好的当然是经常用到的东西，自己对其本身的功能已经很熟悉了，甚至说内部实现机理都能略说一二，这时候读起来肯定更省力。

教就是学
读码之后写文章也不错，有时候你以为自己读懂了，真提笔要写一个模块分析的时候，突然发现还有东西是模糊的，或者前后逻辑串起来是矛盾的，这种事也常有。于是我一直认为，能真正写出一篇让人看得懂，没有问题的分析文章，才真的算是读懂了一个模块。

我就先扯到这，期待更多牛人们的分享！

hoterran   软件工程师

40人赞同

谢谢 iammutex 的邀请, 看过一些 c 和 java 的项目,说说经验, 想到哪里说到哪里.

一般开源项目, 如果这个项目你很熟悉经常用, 那么你直接从 main 入手没问题.
如果你不熟悉或者代码量很大, 最好从代码的 example 代码 或者 client 的代码入手比较容易. 这些代码直接 gdb 进去就可以调试运行了, 客户端的功能搞清楚了,会用了, 恐惧感就降下去了, 再看服务端就容易了.

看 c 代码要 关注主体核心 struct , 整个server, client 可能都是围绕整个 struct 运行起来的, 这个struct 的指针 传来传去. 而看 java 代码 就需要关注最主要的 interface, 通过 interface 
看继承类.

有的人喜欢微观从main开始看,有的喜欢宏观先看数据结构(接口), 这个都可以.

另外看网络代码,最要关注的就是 何时 listen, 何时 accept, epoll_ctl 注入的几个函数是谁,对应java 里就是 selector 之后的几个读写函数. 找到这几个函数,基本网络框架就理解了, 网络模型就那么几种.

看网络协议包处理函数可以让你更好的理解干巴巴的协议.

看 help 函数 可以更快的知道 如何使用.

如果代码不好调试, 根据程序运行的日志输出, 在代码里找日志输出点也是一种方法.

自己写一个 cscope.sh 脚本, 放到path里, 代码下载下来在主目录运行一下就可以开看了.

find . -name "*.h" -o -name "*.c" -o -name "*.py" -o -name "*.lua" -o -name "*.erl" -o -name "*.hrl" -name "*.java" >> cscope.files
cscope -bkq -i cscope.files
ctags -R 
ctags -I __THROW --langmap=c:+.h --languages=c --c-kinds=+p --if0=yes --exclude=java --file-scope=yes -f systemtags /usr/include/* /usr/include/sys/*

用 gdb 看代码, 反复进去退出, 写个 macro file 也是不错的

b main
r --user=mysql --gdb --basedir=/usr/local/mysql --datadir=/usr/local/mysql/var --log-error=/usr/local/mysql/var/hoterran-laptop.err --pid-file=/usr/local/mysql/var/hoterran-laptop.pid
set scheduler-locking off

gdb -x macro-file libexec/mysqld

gdb --args 挺好用的, 很多人喜欢在 gdb 里输入参数多麻烦阿.

vim 的 ctags, cscop只能利用symbol 来查找还是弱了一点, 用 eclipse 看 java 就更加方便了, 看 扩展类, 看调用关系都是一个右键可以搞定的. java 项目可以利用 maven 把依赖的jar的 source 都下下来.

我一般习惯左边显示器开代码(vim, eclipse). 右边我一般会开个 xmind, dia 或者 luchidchart, griffly 画画uml流程时序图什么的.尤其多线程的程序, 各种 lock 和 queue 调用, 你没有图比较难理清楚思路. 纸笔有的时候更加效果.

个人觉得代码比看书更应该有产出, 我们可以看闲书一扫而过, 看代码最好还是记点笔记, 画个图. 方便回忆,方便continued.

另外@李创@刘炜 同学都是看代码的高手,大家可以多关注他们的博客.

编辑于 2013-12-24 2 条评论 感谢

收藏 • 没有帮助 • 举报 • 作者保留权利

阅读别人的代码作为开发人员是一件经常要做的事情。一个是学习新的编程语言的时候通过阅读别人的代码是一个最好的学习方法，另外是积累编程经验。如果你有机会阅读一些操作系统的代码会帮助你理解一些基本的原理。还有就是在你作为一个质量保证人员或一个小领导的时候如果你要做白盒测试的时候没有阅读代码的能力是不能完成相应的任务。最后一个就是如果你中途接手一个项目的时候或给一个项目做售后服务的时候是要有阅读代码的能力的。

　　收集所有可能收集的材料

　　阅读代码要做的第一件事情是收集所有和项目相关的资料。比如你要做一个项目的售后服务，那么你首先要搞明白项目做什么用的，那么调研文档、概要设计文档、详细设计文档、测试文档、使用手册都是你要最先搞到手的。如果你是为了学习那么尽量收集和你的学习有关的资料，比如你想学习linux的文件系统的代码，那最好要找到linux的使用手册、以及文件系统设计的方法、数据结构的说明。(这些资料在书店里都可以找到)。

　　材料的种类分为几种类型

　　1.基础资料。

　　比如你阅读turbo c2的源代码你要有turbo c2的函数手册，使用手册等专业书籍，msc 6.0或者java 的话不但要有函数手册，还要有类库函数手册。这些资料都是你的基础资料。另外你要有一些关�8�些没�%6��可以作为查询手册也是一个不错的选择

　　3.相关项目的文档资料

　　这一部分的资料分为两种，一个相关行业的资料，比如你要阅读一个税务系统的代码那么有一些财务/税务系统的专业资料和国家的相关的法律、法规的资料是 必不可少的。此外就是关于这个项目的需求分析报告、概要设计报告、详细设计报告，使用手册、测试报告等，尽量多收集对你以后的代码阅读是很重要的

　　知识准备

　　了解基础知识，不要上来就阅读代码，打好基础可以做到事半功倍的效果

　　留备份,构造可运行的环境

　　代码拿到手之后的第一件事情是先做备份，最好是刻在一个光盘上，在代码阅读的时候一点不动代码是很困难的一件事情，特别是你要做一些修改性或增强性维护的时候。而一旦做修改就可能发生问题，到时候要恢复是经常发生的事情，如果你不能很好的使用版本控制软件那么先留一个备份是一个最起码的要求了。

　　在做完备份之后最好给自己构造一个可运行的环境，当然可能会很麻烦，但可运行代码和不可运行的代码阅读起来难度会差很多的。所以多用一点时间搭建一个环境是很值得的，而且我们阅读代码主要是为了修改其中的问题或做移植操作。不能运行的代码除了可以学到一些技术以外，用处有限。

　　找开始的地方

　　做什么事情都要知道从那里开始，读程序也不例外。在c语言里,首先要找到main()函数，然后逐层去阅读，其他的程序无论是vb、delphi都要首先找到程序头，否则你是很难分析清楚程序的层次关系。

　　分层次阅读

　　在阅读代码的时候不要一头就扎下去，这样往往容易只见树木不见森林，阅读代码比较好的方法有一点象二叉树的广度优先的遍历。在程序主体一般会比较简 单，调用的函数会比较少，根据函数的名字以及层次关系一般可以确定每一个函数的大致用途，将你的理解作为注解写在这些函数的边上。当然很难一次就将全部注 解都写正确，有时候甚至可能是你猜测的结果，不过没有关系这些注解在阅读过程是不断修正的，直到你全部理解了代码为止。一般来说采用逐层阅读的方法可以是 你系统的理解保持在一个正确的方向上。避免一下子扎入到细节的问题上。在分层次阅读的时候要注意一个问题，就是将系统的函数和开发人员编写代码区分开。在 c, c++，java ,delphi中都有自己的系统函数，不要去阅读这些系统函数，除非你要学习他们的编程方法，否则只会浪费你的时间。将系统函数表示出来，注明它们的作用 即可，区分系统函数和自编函数有几个方法，一个是系统函数的编程风格一般会比较好，而自编的函数的编程风格一般比较会比较差。从变量名、行之间的缩进、注 解等方面一般可以分辨出来，另外一个是象ms c6++会在你编程的时候给你生成一大堆文件出来，其中有很多文件是你用不到了，可以根据文件名来区分一下时候是系统函数，最后如果你实在确定不了，那就 用开发系统的帮助系统去查一下函数名，对一下参数等来确定即可。

　　写注解

　　写注解是在阅读代码中最重要的一个步骤，在我们阅读的源代码一般来说是我们不熟悉的系统,阅读别人的代码一般会有几个问题，1搞明白别人的编程思想不 是一件很容易的事情，即使你知道这段程序的思路的时候也是一样。2阅读代码的时候代码量一般会比较大，如果不及时写注解往往会造成读明白了后边忘了前边的 现象。3阅读代码的时候难免会出现理解错误，如果没有及时的写注解很难及时的发现这些错误。4不写注解有时候你发生你很难确定一个函数你时候阅读过，它的功能是什么，经常会发生重复阅读、理解的现象。

　　好了，说一些写注解的基本方法：1猜测的去写，刚开始阅读一个代码的时候，你很难一下子就确定所有的函数的功能，不妨采用采用猜测的方法去写注解，根 据函数的名字、位置写一个大致的注解，当然一般会有错误，但你的注解实际是不但调整的，直到最后你理解了全部代码。2按功能去写，别把注解写成语法说明 书，千万别看到fopen就写打开文件，看到fread就写读数据，这样的注解一点用处都没有，而应该写在此处开发参数配置文件(****。dat)读出 系统初始化参数。。。。。，这样才是有用的注解。3在写注解的使用另外要注意的一个问题是分清楚系统自动生成的代码和用户自 己开发的代码，一般来说没有必要写系统自动生成的代码。象delphi的代码，我们往往要自己编写一些自己的代码段，还要对一些系统自动生成的代码段进行 修改，这些代码在阅读过程是要写注解的，但有一些没有修改过的自动生成的代码就没有必要写注解了。4在主要代码段要写较为详细的注解。有一些函数或类在程 序中起关键的作用，那么要写比较详细的注解。这样对你理解代码有很大的帮助。5对你理解起来比较困难的地方要写详细的注解，在这些地方往往会有一些编程的技巧。不理解这些编程技巧对你以后的理解或移植会有问题。6写中文注解。如果你的英文足够的好，不用看这条了，但很多的人英文实在不怎么样，那就写中文注解吧，我们写注解是为了加快自己的理解速度。中文在大多数的时候比英文更适应中国人。与其写一些谁也看不懂的英文注解还不如不写。

　　重复阅读

　　一次就可以将所有的代码都阅读明白的人是没有的。至少我还没有遇到过。反复的去阅读同一段代码有助于得代码的理解。一般来说，在第一次阅读代码的时候 你可以跳过很多一时不明白的代码段，只写一些简单的注解，在以后的重复阅读过程用，你对代码的理解会比上一次理解的更深刻，这样你可以修改那些注解错误的 地方和上一次没有理解的对方。一般来说，对代码阅读3，4次基本可以理解代码的含义和作用。

　　运行并修改代码

　　如果你的代码是可运行的，那么先让它运行起来，用单步跟踪的方法来阅读代码，会提高你的代码速度。代码通过看中间变量了解代码的含义,而且对 以后的修改会提供很大的帮助

　　用自己的代码代替原有代码，看效果，但在之前要保留源代码

　　600行的一个函数，阅读起来很困难，编程的人不是一个好的习惯。在阅读这个代码的时候将代码进行修改，变成了14个函数。每一个大约是40-50 行左右.

———————————————源码下载网站—————————————————————

跟你说几个我常用的源码下载网站

csdn（中文IT社区）它是集新闻、论坛、群组、Blog、文档、下载、读书、Tag、网摘、搜索、.NET、Java、游戏、视频、人才、外包、第二书店、《程序员》等多种项目于一体的大型综合性IT门户网站，源码只是其中的一项，但是很实用 里边有很多大牛。

DevStore（源码下载_DevStore）主要是开发者服务平台，汇集国内外众多第三方开发者服务，为开发者提供从设计开发到运营推广一站式的解决方案，源码和服务评测也是亮点，很专业，很实用，这里边聚集的都是开发者和PM，可以看看。

站长之家（网站源码）针对个人站长，企业网管提供的资讯和源码，包含的语言和类型也比较多。