如何阅读源码

如何阅读源码

前言

关于阅读源码会有很多感悟，本篇仅是先行文章，后续将继续更新体验，亦有可能拆分多篇。

最近源码看得越来越多，遇到了一些编程的问题，也越来越喜欢直接去查看源码和官方文档，而不是随便上论坛搜答案。除非是一些总结性的或者讨论性的问题，亦或是为了迅速得到某一个答案而不关心具体问题，才会在论坛找答案。

这也是看源码的好处，当为了某一个问题去看源码的时候，其实不仅仅是解决了遇到的问题，对编码能力也会有显著帮助与提高。最直接不过的就是，可以学习优秀代码风格和编程规范，代码结构组织和设计模式。同时还可以看看别人在设计模块的时候，引用了一些什么自己尚且不知道的模块，这些模块往往也是作者设计的模块得以保证性能的原因之一，在未来自己的编码工作中，也可以适时引入。

很多时候，解决一个问题，靠空想或是完全创新性的得到一个解决方案是非常不容易的，能做到的当然最好。只不过，很多时候，解决问题才是关键，解决方案是什么不是最重要的。也许会一直打补丁，那说明，问题并没有真正解决，那就找新的解决方案。所以核心是问题。既然无法创造性的想出解决方案，很多时候就会陷入到死循环牛角尖之中。而如果能够模仿一些其他人的方案，无论是实际操作中的方式，或是思想上的指引，都会对自己为问题提出解决方案带来很大的益处。

举一反三是最高效的学习方式，看源码则是基础的一。

接下来谈谈自己在读源码中总结的经验。

使用IDE阅读

基本所有的源码是在git上存储的。以github为例，无论只是看某一模块，还是看整一个大项目，都应该把代码完整的clone下来。在IDE中阅读的一个好处是，方便的访问函数和类，既有助于从宏观上对整个项目的源码结构有一个基本的了解，又可以迅速的找到希望阅读的细节。

只看想看的模块

对于源码阅读，最忌讳的是，像读书一样，然后一篇一篇翻看源码。这种做法仅有一个好处，那就是看一下代码里面实际使用的某些特别的办法，犹如看文章的时候，看一下文中引用了哪些好词好句，在自己写文章的时候可以效仿引用。但这是所有读源码都可以有的收获，如果仅是抱着这种目的去阅读源码，那么阅读源码的价值会打很大的折扣。

阅读源码，应该带着某一个想要了解的功能细节，去深挖。举个例子，在阅读ali的oss python SDK的时候，我对于他如何设计基于分片上传的接续上传充分感兴趣。这其中包括了，本地文件解析，单文件拆多个类文件，文件多线程上传，对传输过程进行标记，对接oss API，完成上传并删除标记，重新传输时的文件完整性及一致性校验等。

由核心的过程标记，删除标记到多线程，再到文件解析与拆分，根据重点目标逐层阅读。而这个过程的开启，是源自掉用某一个方法时针对该方法的源码开始进行的。

插入调试

以python为例，将过程print出来，有利于理解他的调用，对于简单的调用，当然是非常显著，对于复杂的调用，使用debug会更加清晰。

阅读源码不是阅读英文书，一边读要一边使用，这样才有利于形成更深刻的理解。就像读五线谱，读每一个音符，是无法体会音乐的美妙的，要哼出声音，或者弹奏出来，才能赋予乐章灵魂与生命。

必要的注释与总结

注释，犹如读书笔记，对于将进行多次阅读的代码，插入注释有利于再次阅读时，提取已有的信息。

根据阅读体验，书写总结。可能是感悟，可能是技术使用技巧，也可能是对该源码的指导意见，均可以书写出来。当只有输入的时候，你会觉得只有一个人在战斗，当把习得的知识输出之后，你会发现不止你一个人在战斗。不要觉得自己写的东西大家都写过，没有人看。你现在看到的我写的这篇，很多人都写过了类似的文章，但你还是看到我的。唯一需要做的就是输出有质量的信息，避免浪费自己的时间，和别人的时间。

Show me your code

看各种各样的文档，是以人类比较好理解的语言去阅读；直接阅读源码，是以机器比较好理解的语言去阅读。本质是没有差别的。但是，尽可能多的阅读源码，对写代码的好处是非常大的。如同学习第二外语，多听说读写外语，比看各种关于该外语的历史结构描述等，要进步的快得多。

从头开始读

如果希望从头开始读整个包或者模块，那么一定要先看一下整个的架构。最忌讳的就是一行一行看，且不说不一定能够看懂在做什么，即使看懂了每一行的操作，到头来也很难清晰把握整个模块发挥的左右。从头开始看，一般最主要的目的是要看他如何设计一个架构的，自己学设计模式，要用起来很难，但是看别人已经完成的模块，就知道怎么应用了，依样画葫芦的应用也就有法可循。其次是代码里面有一些创新的设计点，不一定是架构上的，而是某一个方法让一些操作变得逻辑简单清晰，这是很值得挖掘的。最后是看代码风格本身有没有什么学习借鉴的地方，看多了会发现，很多所谓的代码风格比如一个函数方法内的实现不要超过多少行，或者对于魔术数黑魔法的各种拒绝，都可以在一些大牛的包里面看到，然后自己也意识到并不是一定不可以有一些不好的代码出现，关键还是代码本身发挥的作用，至于那些黑魔法只要保证维护成本在可控范围内，也并不是什么大不了的事情。