程序员阅读源码是一种什么心态？源码对编程意义何在？如何才能更好阅读代码？

(难道大家都想和我搞基，那就公布github id吧:

)

楼下冯东说得较好，“读”标识符是不能给你增添任何收益的，正像“念书”那样，假如大三的这时候你不思量，看管你念完年半准忘了大半。真正须要的是去“试”标识符，亲自动手去盛气凌人标识符，啥这时候这啥这时候那，看看把A变成B那个标识符的结果会有甚么变化。

难道他讲了规矩，那我就来推荐两个二要可操作且早已被证明（被我）有实效的方法吧：直接去github上（咱就假定早已开放源码了吧），找找它的issues。

举个范例，你对大信息处理钟爱，你听说了Twitter公司出品了两个牛逼飞舞的写map-reduce的辅助工具，查到了它的github主页 (

)

然后看到左边的”issues”了么？点它，你就能看见现在那个项目里，还有甚么样难题能/须要解决。

为甚么一定要找难题？记不提过原本初中英文同学告诉你：写作认知要先看难题，带着难题去找标准答案。那个不是没根据的，读源标识符也是那样，假如你是心不在焉地读，那么给你博热县，没几个人会把它给“读”下来，因为通常的标识符都太大太大了，现代计算机系统早已发展到了即使是两个小小应用软件，也够你用两三年的时间就能深入细致到知道始末，知道里面的每个技术细节。

这给企图“读”标识符的新手增添了很大的困难（我原本也想不通这难题，而且我还问过这难题！或者说当时没知乎我就问的旁边的人而已）。当你想拿起linux的标识符拼读，刚把Mach读了一点儿，前面刚知道前面又忘了吧。更何况，仅“读”的这时候，会给你一类幻觉——让你感觉你啥都读到了一点，博热县你来雀舌木啥这时候的话，看管根本无法亲自动手。

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

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

)之后会出现:

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

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

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我，给我加星啥的，一起搞基啥的，萌萌哒