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