很多人觉得具备阅读代码能力的人很牛逼，自己也试着做过阅读，但发现一掉进去总是会迷失方向却最后无所获取，不知道该如何正确阅读代码。

作者：谢科 链接：https://www.zhihu.com/question/29765945/answer/47725158 来源：知乎  

“读”代码是不能给你带来任何收益的，正如“读书”一样，如果在读的时候你不琢磨，保管你读完仨月准忘了一大半。真正需要的是去“试”代码，动手去调调代码，改改这改改那，看看把A变成B这个代码的结果会有什么变化。

既然他讲了道理，那我就来推荐一个切实可操作且已经被证明（被我）有成效的方法吧：直接去github上（咱就假设已经开源了吧），找找它的issues。

举个例子，你对大数据处理感兴趣，你听说了Twitter出品了一个牛逼闪闪的写map-reduce的工具，搜到了它的github首页 (

twitter/scalding · GitHub

)

然后看到右边的"issues"了么？点它，你就可以看见现在这个项目里，还有哪些问题可以/需要解决。

为什么一定要找问题？记不记得当初高中英文老师告诉你：阅读理解要先看问题，带着问题去找答案。这个不是没有根据的，读源代码也是一样，如果你是漫不经心地读，那么给你打包票，没有几个人能把它给“读”下来，因为通常的代码都太大太大了，现代计算机已经发展到了即使是一个小小的软件包，也够你用三五年的时间才能深入到明白前因后果，明白里面的每个细节。

这给试图“读”代码的初学者带来了极大的困难（我当初也纳闷这问题，而且我还问过这问题！只不过当时没知乎我就问的边上的人罢了）。当你想拿起linux的代码来读，刚把内核读了一点点，前面刚明白后面又忘了吧。况且，仅“读”的时候，会给你一种错觉——让你感觉你啥都读到了一点，真要你来动动改改的话，保管没法动手。

那么这时候，去github解issue的好处就体现出来了。

拿这个项目来说，你点了issue (

Issues · twitter/scalding · GitHub

)之后会出现:

有没有看到那个beginner? 猛戳呀！意思就是，这个项目的开发者认为，这个issue可以由你这样的初学者来解决。

凭啥你要帮他写代码作嫁裳呢？关于贡献开源软件的哲学争辩我就不多说了，简单讲讲益处有几个

2和3就不多说了，不切题，属于其它益处，说说1吧。

为啥解个issue可以帮你“读”代码？

简单，因为一个issue足够小，而且多数属于可分割的小任务（尤其是标了个beginner的那种，快抢啊！）。我就不引用研究了，你自己的体验应该也会告诉你：当你在试图解决手里的一个小任务，而不是被一个大任务吓到的时候，你会更专注，更容易下手。

那么好，你开始解这个issue了。为了解决一个小问题，你至少得知道这个小问题是由啥引起的吧？这样就引导着你“带着问题读文章”了。相信我，这个时候读的效率，远高于吊儿郎当左翻右翻。

读着读着，发现卡住了。咋办？

解issue的第三个好处又来了，既然你在热心地帮人家解决问题，要是你在试图解决问题的这个过程中遇到了问题，人家肯定也愿意来帮你解决这个因为试图解决问题而遇到的问题呀！（嗯我故意的）。我的经验表明，只要你谦虚好学，牛逼大牛也肯跳出来教你

第四个，解issue可不光只是读代码哦，你要改代码。改的过程中自然而然你得跑test吧，test不过你又得改吧？这叫啥？这叫正反馈啊亲！而且这样的正反馈来得极其迅速，差不多你改一点，五分钟内你知道你改得对错。读代码的时候有这效果吗？没有呀，回忆一下上一次，你读完了一段二分，觉得明白了，没去写写。面试的时候去写，大汗淋漓，写了半天写不对（编程珠矶里的故事啦），为啥？因为你的大脑骗了你，它觉得你肤浅（superficial)地以为自己懂了，其实你还没懂它就已经累了要求你跳过了。

而有正反馈的机制就不一样了，我才不信一片compliation error的时候你的大脑能骗你test过了呢，哼！

第五个，成就感。这个不用我说吧，就像打网游打怪一样，你解了多少issue，猎头姐姐是看得见的哟！下次没准就约你喝咖啡去了。

个人觉得最有益的读源码方式是去帮那个源码项目解issue（当然它如果是个内部项目，那你就内部解嘛，不一定要到基友平台github上啦）。而因为解issue的特性，它是我目前感觉到的，最快迅的深入了解一个library的方法。