其实我开始读源码才几天时间，但有点心得，就写出来吧，以期抛砖引玉。
阅读源代码的利弊我不谈，我只说该如何读
首先是积累，当到了一定条件，你会迫不及待的想要去读，因为你想拥有程序的控制权

我把一份陌生的源代码比做一个陌生的城市，你将在里面熟悉道路，
你只要从一个大的标志开始进入（程序入口点）然后你面临很多分支，有的分支很明显的（依靠设计模式，oo，模块化，结构化，解耦，经验判断，当然还有文档，注释，别人的源码分析文章）与其它没有什么瓜葛，或者只有几个联系点，其实是一个模块化功能，就像你知道有一条路通向xx村，你先不管它，知道它通哪里就可以了，以后再专程访问xx村。

一个设计优良的程序肯定是一个个通过乡村高速公路连接的村落，而不该是交杂在一起的钢筋水泥，至不济也该是用围墙围起来的一个个小区。

当你知道并熟悉了城市的主干道之后，整个城市其实已经成竹在胸了

你该学好模式，oo，模块化，结构化，解耦，接口，多态。。。。
广义来说就是oo

如果这些你都很牛的时候，有份源码还让你读不懂，直接ctrl+del

写给初学的人，以让他们少走不成器的我走过的弯路。

补充一条找源码分析文章的技巧
在google中输入关键的源码片段

补充一点经验：
当你读过一些模块之后，看到类似的模块就会下意识的去猜测该模块内部的代码结构，如果你读的够多，实践够丰富，模块就了然于胸了。
比如看到一个方法名，根据方法的字面意思就能猜测出该方法的代码结构，看到类名，就可能会猜测出它该要有什么方法。
这时读代码的速度就快了。
代码是一个有机体，当你具有把一份源代码解构成一个有机体的能力的时候，读代码其实并不痛苦。可是我还没有达到我想像的哪个层次。

我觉得新手不应该去读。。。
首先读不懂，反而会降低自己的兴趣，把自己脑袋搞得跟浆糊一样

稍微觉得自己有点实力的人，应该跟着程序的执行流程去读，看看别人是怎么实现某个功能的，在实现这个功能中用到了什么方法，也就是跟代码

牛人才能在全局上把握，比如，对spring的IOC，牛人肯定心理会觉得应该这样去实现，应该用到什么设计模式，应该如何设计，这些在牛人的心理大都有个谱了，然后带着验证的心态去读，看看作者和自己想的是不是一样，然后总结，加深。

我觉得如果能站在一个高度去审视别人的代码，把握住大方向，就算是牛人了

对于源代码,我只能读懂小部分,我认为即便是大牛,全读懂也很困难.原因是别人代马里很多状态数据很难判断是干吗的,代码无非是状态+流程,如果每个数据状态都明白,流程应该不难,可是很多代码里有私有算法和状态无法理解,而且这些东西也不会出现在文档里.比如读Hassian的源码,我最感兴趣的就是Hassian如何处理流的,结果就是Hassian的包中的那些自定义流最难懂,比如 final String xxxx = "OX4f";谁知道这0x4f代表什么.

源码之下，了无秘密，一个没有好奇心的人，是不适合做程序员的！

读代码主要是想弄清楚代码想要体现的思想，那么建议先弄清楚你看的代码主要的功能以及思想，带着这些问题去看，最直接的方式应该是弄个TestCase跑跑，跟着走就OK了。让它带着你走，比你自己找路来的快吧！？

哈哈··好奇害死猫啊。

读源码好，能够理清思路，不然的话就成了黑盒程序员，就像微软的xxx技术、xxx语言，搞到程序员都去写黑盒程序去。。。

关键问题是:如何从源码中获得东西,你读懂归读懂,总结出了然后用于提高自己代码的东西有多少??

读源码不难啊，带着问题读，找到代码实现的主线，顺着线走，当然会遇到很多分支，可以自己判断这些分支重不重要来决定是不是需要深入。
个人觉得读源代码很有必要，这样让自己对系统有个全局的感觉，看到一个抛出的异常都知道发生了什么。这样在做应用就很方便了。
读源码和实现源码还不是一个难度层次上的啊！但可以为我们写好代码做积累。
熟读源码三百段，不会写来也会偷

爱干点啥就干点啥，关键是自己觉着是否有收获，是否爽~~~

读书破万卷，下笔如有神。结合我的感受表达一下我的想法：

读懂代码的最高标准是熟悉代码所有的功能实现，了解所有的状态变量，清楚所有配置参数的作用。但如果达到这样的标准能代表什么呢？当然肯定能用好代码，但更重要的是要深入理解代码解决问题域的思想、算法、灵活扩展，一定带着问题领域难点取读，看代码是如何解决的？我们读代码的最终目的是理解代码解决问题域的思想。只有理解了读懂的代码才能为你服务，否则永远停留在会用上。

读源代码的主线是找到入口，顺着流程走下去就ok了
如果像spring这样有自己的TestCase看起来就更顺了，至少是自己呆着问题去读的
其实读了之后，自己需要去感悟，为什么是这样设计的，怎么起变量名，怎么把大方法分成小方法，怎么加注释，一切都需要自己去感悟的

建议在阅读的过程中同时将类图画出来，最后回顾起来对整个程序的架构和设计思路就能够一目了然。

我觉得可以读活的代码,而不是像看书那样地读.
活的代码是在IDE中设置断点后, 看代码的执行顺序.

读源代码让我想起了高中作语文阅读理解题的感觉,你要从有限的代码中读出代码本身并没有提及的问题..需要一定的基础知识
为什么作者这里使用内部类,而不把类分离出来?;为什么作者写了abcHelper类而不把指责直接付给ABC类本身?;这里为什么要用回调,回调降低了谁和谁的耦合度?......我觉得源码里面先从jdk源码搞起效果较佳,因为JDK具备了大多数JAVA针对某些问题习惯性或者说经典实现方式

嗯，说说我怎么读源码，把整个包或应用导入Eclipse中，然后找主类（其他随便都行），看到哪个类或方法不懂，直接Ctrl+点击过去，看具体实现，有点递归查看的意思。这样比较方便。

我觉得楼主说的挺好，我新接手一个项目，需要读代码，发现我理解的比较透彻的地方，都是用的我比较熟悉的模式。
学习高手的代码，基础还是比较重要的。

应该是基本功，熟悉风格，熟悉规范，方能驾轻就熟。

break point tracing。这是我的习惯。

其实楼主说得对.....想做好程序员读不懂代码怎么思考啊..多看别人写的代码...自己也有一些新的想法...也许别人的做参考,自己可以比别人写得更好....不过我看代码主要看思想....

OO基础都不会的话，读别人的代码，的确很累。首先OO的根本其实不光光什么继承，多态，那只是应用到计算机里的东西。OO思想的根本就是你看到一个东西，就能分出他的大类是什么，大类里的小类是什么，它们各有几种属性，会有几个方法。然后才是进行写代码，当然这个时候封装，继承和多态才都会去到，如果用不到，那就再好好理理清。
建议大家去读读“编程之道”。读上几遍，会很有收获。

主要通过功能去跟踪，然后再回归到整体

读源码的好处是显而易见的，但关键是你能不能读懂。
我觉得，首先你要看你是不是有这个能力，想LZ这种方法是可以的，想将源码的主干弄清楚，再解决细节问题，分而治之，逐层解析，很好的方法，这个关键还取决于你所看的源码是按照模块化\OO思想编写出来的，而且逻辑非常清楚，不然也没有用。就着编写者的思维去看源码，你会更有效率。