(既然大家都想和我搞基，那就公布github id吧:
oeddyo (Eddie Xie) · GitHub)
楼上冯东说得很好，“读”代码是不能给你带来任何收益的，正如“读书”一样，如果在读的时候你不琢磨，保管你读完仨月准忘了一大半。真正需要的是去“试”代码，动手去调调代码，改改这改改那，看看把A变成B这个代码的结果会有什么变化。
既然他讲了道理，那我就来推荐一个切实可操作且已经被证明（被我）有成效的方法吧：直接去github上（咱就假设已经开源了吧），找找它的issues。
举个例子，你对大数据处理感兴趣，你听说了Twitter出品了一个牛逼闪闪的写map-reduce的工具，搜到了它的github首页 (
twitter/scalding · GitHub)
然后看到右边的"issues"了么？点它，你就可以看见现在这个项目里，还有哪些问题可以/需要解决。
为什么一定要找问题？记不记得当初高中英文老师告诉你：阅读理解要先看问题，带着问题去找答案。这个不是没有根据的，读源代码也是一样，如果你是漫不经心地读，那么给你打包票，没有几个人能把它给“读”下来，因为通常的代码都太大太大了，现代计算机已经发展到了即使是一个小小的软件包，也够你用三五年的时间才能深入到明白前因后果，明白里面的每个细节。
这给试图“读”代码的初学者带来了极大的困难（我当初也纳闷这问题，而且我还问过这问题！只不过当时没知乎我就问的边上的人罢了）。当你想拿起linux的代码来读，刚把内核读了一点点，前面刚明白后面又忘了吧。况且，仅“读”的时候，会给你一种错觉——让你感觉你啥都读到了一点，真要你来动动改改的话，保管没法动手。
那么这时候，去github解issue的好处就体现出来了。
拿这个项目来说，你点了issue (
Issues · twitter/scalding · GitHub)之后会出现:
有没有看到那个beginner? 猛戳呀！意思就是，这个项目的开发者认为，这个issue可以由你这样的初学者来解决。
凭啥你要帮他写代码作嫁裳呢？关于贡献开源软件的哲学争辩我就不多说了，简单讲讲益处有几个
你可以真正地通过解这个issue来帮助你自己了解这代码是在干嘛它给你一个跟世界上最顶尖的程序员交流的机会（为毛？因为你写完了人家要给你review呀亲！）而且这是免费的哦！顺便，你的贡献还可以当作你最不可争议的简历2和3就不多说了，不切题，属于其它益处，说说1吧。
为啥解个issue可以帮你“读”代码？
简单，因为一个issue足够小，而且多数属于可分割的小任务（尤其是标了个beginner的那种，快抢啊！）。我就不引用研究了，你自己的体验应该也会告诉你：当你在试图解决手里的一个小任务，而不是被一个大任务吓到的时候，你会更专注，更容易下手。
那么好，你开始解这个issue了。为了解决一个小问题，你至少得知道这个小问题是由啥引起的吧？这样就引导着你“带着问题读文章”了。相信我，这个时候读的效率，远高于吊儿郎当左翻右翻。
读着读着，发现卡住了。咋办？
解issue的第三个好处又来了，既然你在热心地帮人家解决问题，要是你在试图解决问题的这个过程中遇到了问题，人家肯定也愿意来帮你解决这个因为试图解决问题而遇到的问题呀！（嗯我故意的）。我的经验表明，只要你谦虚好学，牛逼大牛也肯跳出来教你
第四个，解issue可不光只是读代码哦，你要改代码。改的过程中自然而然你得跑test吧，test不过你又得改吧？这叫啥？这叫正反馈啊亲！而且这样的正反馈来得极其迅速，差不多你改一点，五分钟内你知道你改得对错。读代码的时候有这效果吗？没有呀，回忆一下上一次，你读完了一段二分，觉得明白了，没去写写。面试的时候去写，大汗淋漓，写了半天写不对（编程珠矶里的故事啦），为啥？因为你的大脑骗了你，它觉得你肤浅（superficial)地以为自己懂了，其实你还没懂它就已经累了要求你跳过了。
而有正反馈的机制就不一样了，我才不信一片compliation error的时候你的大脑能骗你test过了呢，哼！
第五个，成就感。这个不用我说吧，就像打网游打怪一样，你解了多少issue，猎头姐姐是看得见的哟！下次没准就约你喝咖啡去了。
好，总结一下吧：
个人觉得最有益的读源码方式是去帮那个源码项目解issue（当然它如果是个内部项目，那你就内部解嘛，不一定要到基友平台github上啦）。而因为解issue的特性，它是我目前感觉到的，最快迅的深入了解一个library的方法。
非要credibility吗？好吧，仨月前其实我只是上面那个project的用户，解着解着issue现在也算排名靠前的贡献者了吧。欢迎来github上follow我，给我加星啥的，一起搞基啥的，萌萌哒
首先要说明的是，代码不是小说和其它文字作品，代码不能「读」。我们平时所谓的「读」代码其实是 explore 或者 decypher。
所以读代码有很强的目的性，也需要有很多先决条件。第一个先决条件是知道这个 code base 的用途和用法。然后要了解工作的基本原理。最好还要有 high-level design 的文档。
目的性可以有两种：第一是扩展 code base 增加原本没有的功能。这个分为以下几步：
首先要假想系统是如何工作的。这种假象要着重在为什么所需的功能现在没有提供，如果实现的话大体难度是什么。阅读代码部分验证或者推翻原来的想法。这种阅读要结合 debugging。建立新的假想，重复第二步。如果假想与所看的 code 基本吻合，尝试修改 code。测试。如果测试不能通过，退回到第四部甚至第二部。第二种是验证某些想法。这种阅读是上面过程的第 1-3 步。这种过程中的假想可能是一个归谬的假象——也就是说，根据系统的 high-level design，推断出某个功能无法实现，但是现实中的 code base 提供了这个功能。需要通过 explore code 来解释假想为什么是错误的。
总之，代码是不可能像小说那样去「读」的。在 explore 之前就必须做好足够的功课。我阅读代码从来不会在没有「假想」的情况下无目的的瞎看。Explore 代码和物理实验有类似之处，没有经过设计的实验时没有收获的。
读代码至少和你写代码一样重要。
特别是读比你水平高的人写的代码。
特别是你不只是读了还fork了。
特别是你不止fork了，还hack了。
特别是你不止hack了还PR了。
我觉得读源代码是边际效益偏低的学习方式，学习一个新技术还是应该以看文档和学习相关理论为主。比如说你学数据库，看源代码就太累了，不如学理论直接和实用。等到你想具体深耕某种特定的技术，并希望给开源项目做贡献了，再阅读源代码也不迟。
我一般都是我要debug或者给这个项目添加新feature，或者说打算提交pull request了，才会开始看源代码。或者我想借鉴某个项目的具体实现，我可能也会去看看它的源代码。我一般都会有明确的目的，只会阅读特定部分的代码，不会通读，因为通读的效益就有点太低了
不推荐以学习的方式去读源码，而是应该产生阅读源码的需求才去读。
第一个是你对这个库的内部实现感兴趣，比如 concurrentHashmap，你想知道内部是怎样实现并发安全的，首先你产生了这个疑问，才去读，这相当于是解惑。
第二个是使用这个库的时候，发现了可能存在的 Bug，通过阅读源代码，试图找到 bug 的源头，可以使用调试工具不断地 step in，然后看问题产生的根源。
第三个是要修改这个库，也就是说这个库不能满足你的需求了，你需要增添一些功能拓展，这时你必须明白源码是什么样的才能进行拓展。
如果你对这个库的内部实现不感兴趣，用着也没什么问题，也没有定制，个性化的需要，完全没必要去读源码，大部分源码其实都是 trivial 的，也就是普通的逻辑，普通的代码，没有能惊艳你的地方，这种代码，读着其实就是浪费时间。