1. 了解项目
读相关的文档和文章，起码要知道这个项目是用来干嘛的，有什么样的功能，运行在什么上面（手机，PC，或多平台），发行许可（GPL，Apache或者？？），目标格式（应用程序，库，中间件等）等等。通常这些问题在项目的文档，Wiki，FAQ等地方都 能找到。
2. 获取源代码
这不用多说，没源码你还研究个啥，这个官方文档会讲，通常都是通过SVN或GIT，当然也有把源码打包下载的（前提是源码比较少）。
3. 编译和构建出可运行的目标产品
后面会讲到，光看源码就好比读布尔代数，或马克思主义一样，都是干巴巴的理论，让人不着边际，摸不到头脑，遗忘的也很快，最重要的是没什么实地用处。通常研究源码都是为了做出改变。
编译和构建项目也都会有专门的文档来讲，遇到的最大的困难就是编译环境的搭建，由于不同开发环境的差异，编译通常都不可能一次成功，这时就要看看官方的FAQ，或是Google一下，还是很容易解决的。
4. 运行
一定要亲自运行一下，玩一玩，看看都有什么功能，都能完成什么事情。要想对项目源码了解，首先必须 要从用户的角度对项目熟悉，各个功能都要试玩并熟悉。尝试一些极端的操作，输入非常规的数据，看看会有什么反应。
5. 如何调试
这个要看什么语言和什么目标文件，总体来讲就是工具和Log日志，工具无非就是Eclipse，GDB之类的，Log要看具体 的项目，每个项目都会有自己的Log机制。查文档或是到网上搜索。
6. 读读单元测试用例
不要上来就看源代码，这样很容易迷失在源码中，特别是当项目的源码很多时，你不知道这个类或这个方法是用来干嘛的，类之间的依赖和关联更让人困惑和畏惧，导致很快失去了兴趣。
可以先读一读单元测试用例，它们是代码的活文档。
7. 抓住一个功能点，深入的调试跟踪流程，分析代码直到弄明白为止
这点很重要，虽然我们要理解整个项目，要从整体上把握，但那需要时间，短时间内是不可能的。更好的方式是抓住一个功能点从上层一直跟踪下去，直到所整个功能点的流程搞清楚，分析代码，画出图（不用标准的UML，能看懂，能表达出意思即可）。
8. 修改源代码，编译运行，看修改前后有什么变化，这是感知代码用途的最佳途径
为了感知代码，做出修改，然后运行，看修改前后的变化，这能很快的感知代码 的作用。特别是对于参数，光看代码很难知道那一大堆参数是干什么用的，修改一下，改成相反的值或是改成不合常规的值，看程序有什么反应，很快便能知道它的作用。
9. 修改单元测试或编写单元测试
这也是感知代码的好方法，编写单元测试，可能会涉及到解耦，如果类之间的关系过于紧密，就要先解耦分离，这里可能读读Michael Feather的《Working with Legacy Code》中的”感知与分离”一节。
10. 尝试弄清整个项目的业务逻辑
这是必须要做的，要想研究项目，或是维护项目弄清楚项目的整体业务逻辑是必须要做的，但这需要时间。所以不能放弃，视项目的大小这通常要花上数月甚至数年。点滴积累，每天看一点，时间久了对整个项目就熟悉了。
关键点在于要各个击破，不要光看代码。抓住一个功能点，跟踪，调试，修改，运行，把它搞明白，再转向其他的功能点，当把所有的功能点都搞明白后，对整个项目就自然清楚了。
11. 参考项目的文档和别人写的文章
这可以加速对代码和业务逻辑的理解。最好参看项目的文档（设计文档等），但是很多的项目是没有文档的。
对于网络上的文章一定要持有怀疑之心，可作参考不可依赖，更不可全信。其价值完全取决于作者的水平 及作者对项目代码的理解程序，与其写作能力和花在文章上的时间也有关系。网上的好文章很少，刚开始只有几篇文章，随后会出现大量的Copy和转载，所以对于某些问题你会发现搜到的文章其实是同一篇，换句话说就是整体的质量不高。其中也有错误的或是误导人的。再加上时效性的问题，项目代码会持久更新，但发布出去的文章却很少有人更新它。所以对于网络上的文档必须持有怀疑的态度。
另外，最好用Google搜英文的文章，通常来讲外国人写的文章还是比较有参考价值的（国人很浮躁啊）。
12. 当对项目和代码有一定了解之后可以写文档或文章以加深自己的理解，也分享给别人自己的心得体会
写文章，画图表，这是检验自己对项目理解的最好方式，你能给别人讲清楚，能让别人也理解这个项目是你理解了这个项目的最好证明。要注意把自己的理解写出来，表照抄代码，照着代码画出来的序列图，证明你对代码不熟悉，也没理解代码，对别人也毫无用处，一定要用自己的话表达出来。这样才能加深自己的 理解，对别人也是一种帮助。