源码到底应该怎么读？

1 走上阅读源码的道路

     从我刚刚开始入行的时候就一直就有很多前辈们提点我，告诉我要读源码，只有阅读源码才能提高自己成为大神。但是始终没有人告诉我到底改怎么阅读源码，阅读源码到底可以怎么提高自己从哪些方面提高自己。就算你从各类论坛网页或者专栏中看到的一些大拿的回答。感觉总是差点意思，还是入不了门。这个行业还有个奇怪的现象，一个人技术很厉害的人讲课传授知识的能力特别垃圾。俗话说不想当架构师的厨子不是好司机，所以一直在重复的去阅读各类源码，看得懂的要看，看不懂的也要看（其实大部分还是可以看懂的，不过雾里看花，仅仅知道它是花而已）。就程序员这个行当而言我相信有百分之七八十的人的目标都是想摆脱CURD，成为大拿、架构等等。直到近些年才有所感触有所体会。首先从几方面谈下我的体会。阅读源码的好处、怎么读源码。希望刚入行或者还有些迷茫的朋友有所参考

2 为什么要阅读源码

        都说源码是最好的老师，但是我们首先要明白源码这个老师有什么能力。可以教给我们什么。凡事要有目的，没有目的最终什么也得不到。下面咱们来谈下我们从源码中可以学习到什么。

• 程序设计

        平常我们谈论最多的就是设计，但是真正开发的时候就是if else。说是工时短，只能代码堆砌，所以自己提升不了，只会CURD.。公司以盈利为目的没有毛病，至于你自己的成长就需要你自己需要想办法去，因为跳槽涨薪又不是你现有公司的事情。

       看源码学习设计，就算你平常找本设计模式的书看再多也是无用的，因为你不知道怎么用，什么时候该用。如果你看源码你就会发现，源码的设计总是可以恰到好处的通过各种设计模式将程序设计的高可用、高扩展。比如Spring设计了很多扩展点，监听器所以他的扩展性才会那么高，我们阅读Spring源码的时候要学习他是怎么实现这些扩展点和监听器的，下次我们写代码是不是也可以在适当的场景下按照它实现的思路去写，还有Mybatis的拦截器、SpringAOP，他们是通过责任链模式和动态代理来实现的它拦截的特性 我们写代码的时候我们是不是也应该有一个高扩展的思想，然后参照源码的实现方式和流程去实现咱们的代码。这仅仅是一个例子，还有很多的设计模式。读源码的时候多问下他为什么这么写，这样设计解决了什么问题。每一种设计模式的应用都要明白他对应的特性和解决类什么问题。如果你想明白之后，你的思路和实现是不是就这一个想法上就和写源码的大神处于同一水平了，当你看源码的时候多考虑设计和问为什么，慢慢的大神的思维和设计就会被你所吸收，慢慢的你就会跟他们处于同一水平。更高的水平就是你看懂了他设计的好处和应用之后，又看到了这种设计的不足，并且能想出设计方案并且解决它，哪你将超越大神。

• 学习知识点

            学习一门语言，包含了很多语法规则和一些其他的高级技术，基础的语法规则支撑我们写平常的代码。但是一些高级的知识可以让我们写出更好的程序和功能，例如并发、IO等技术。

    对于一个初级程序猿而言你只需要了解基础的语法就可以CURD,但是一个程序写到最后肯定是要考虑到并发、锁、IO等方面。但是这些东西我们紧紧去通过学习知识类用书是不太好学明白的。还是那句话不会应用就是白学，过个十天半月也就忘的差不多了。

    通过阅读源码你可以学习到IO怎么用，怎么处理高并发、怎么用锁等等基础知识。在你阅读spring源码的时候你可以看到有些地方使用synchronize、lock你会学到什么场景下使用synchronize、lock.使用锁的最佳实践案例。当你阅读RocketMQ、Kafka的时候你可以学到他们高性能IO的设计方案，以及他们是怎么使用IO知识实现的零拷贝或者页缓存等等。按照这种方式你对基础知识的理解和技术深度越来越深。当你在内心存储了大量的程序设计案例和每个基础知识的深度理解之后，那么自己写个源码级别的项目也仅仅是时间的问题，不会存在什么技术壁垒。所以看源码的时候一定要注意源码对这些基础知识的运用，了解这么用的场景和解决的问题，从设计层面去考虑用这种写法的优缺。

• 代码规范

        代码规范这也是个老生常谈的问题，基本上每个程序员都会跟你强调代码规范的重要性，但是代码就国内的行情来看，代码还是一如既往的烂。哪一坨有一坨的代码除啦自己没人可以搞定，甚至隔一段时间连自己都懵逼。从另一方面而言这样也增加了咱们的不可替代性（玩笑不可取😄）。

    再说个现象。国内一些开源的框架或者技术，虽然实现了很多优秀的特性广为流传，被大众熟知，但是跟国外开源的框架的源码对比还是差点意思的。

        国内的开源框架有几个问题：

        1   代码方法中代码特别的长，缺乏设计

        2 代码注释缺乏（我比较厌恶这点，看个源码学习学习，连个注释都没有，太难受了）

对比下Kafka和Spring的源码你就可以看出差别来，Kafka和Spring的源码中，每个方法每个类的注释哪写的甚至比代码写的还多，方法也是尽量的短，很少说一个方法中出现几百上千行的代码。我以为写代码就好像写文章一样，要段落明晰，不能一坨堆在一坨上，真是写到自己都懵逼，何况看代码的人。还有就是命名的问题，方法名、变量名、方法名看名知意。这点其实国内开源做的还是可以的。国内开源的东西其实在领域编程和抽象设计方面做的还是可以的。

        其实也不能怪咱们国内的程序员没有上进心或水平，毕竟国外和国内环境的差别还是很大的。国内的开源技术大部分都是什么状态，当你听说一种技术之后大部分都是突然或者很快做出来的，从做到流行中间经历了很短的时间。国内是个什么状态哪？就是当某个需要或产品被提出来之后，咱们的公司就给那么点工时，那么咱们的工作流程就是，参照现有的同行业的一些产品，看看他们有什么特性，那么咱们的程序员就会把你需要的现有产品的特性作为设计的目标，并且也会把同行业产品的不足点作为咱们要解决的问题作为咱们产品的新特性。既然需求特性都弄好了，设计设计就可以直接撸代码开干了。咱们明明是个技术工种，却非要逼着咱们搬砖，工时短加加班就可以多搬两块砖。这种情况下代码的质量就堪忧了。你可以放眼国外的开源技术，例如Kafka 设计之初是为了解决 Linkedin 公司数据管道(datapipe)问题，经历了六七年的发展才逐步演变成了现在的架构，才广为流传。所以像国内现在的这种快餐文化很难出现高质量的开源。各有利弊，不能否认的是这种快餐文化的效率很高，很符合前些年国内互联网行业的发展。

    所以就代码规范上我还是比较主张去看些国外的源码的，从实际代码中去提炼代码的规范。无论人或者书本上跟你强调多少遍各种命名规范，都不如去大神的代码中去看看有哪些代码规范。因为那样你就会体会到当你严格遵守代码规范之后，代码的魅力有多大。规范不在多我觉得只要你遵守好几个就可以让你的代码提升好几个等级

   1 变量、方法、类 命名驼峰命名

   2 命名要见名知意（有个好的命名之后，你会发现就算不看注释你都会很容易看都代码的逻辑）

  3 还有就是注释，笔记代码的逻辑和层次感还是比较不好理解的，所以需要对你的代码多多的添加注释，梳理你自己的思路，也方便后来人的观看。国外的技术源码中你会发现很多注释，一个方法的小注释快赶上一个小作文了。还有其他很多的规范。就是只要当你看到源码中跟你平常写的不一样的地方你就需要去考虑下源码为什么这么写，这样写的好处是什么。国内如果按这个要求，现有的工时需要✖️10

• 数据结构和算法

听了很多年的算法无用论，但是真的无用吗，紧紧是为面试吗？当然我不太主张刷题了、看书了去学习数据结构和算法。数据结构和源码的应用你可以在很多源码中看到它的身影，从源码中你就可以找到算法怎么用、优缺点。这时候当现有的jdk的工具不能满足你的需要的时候你是不是可以参照jdk的某些工具中的算法自己写一个算法。jdk都在不断的升级来弥补他们以前版本不能满足的东西。现有的开源框架也有很多很多的算法设计，比如sentinel的滑动时间窗口算法、kafka的分区分配算法等等，每当你设计出一个算法，对于你的产品而言就会多一种产品特性。所以说从现有源码中去学习算法我个人认为是最好的途径。

• 面试：

    面试其实是对于技术而言是最不重要的。每当面试前我们都要刷题，看面试题等等。但是真的记得住吗，就算记得住过一段时间真的可以用上吗？不会忘记吗？就个人而言我觉得面试前的一些列准备于个人成长没有任何意义。所以平时多看源码，你面试的时候就会很容易。看一个源码你从它的原理设计到实现和优缺点都可以得到很好的验证学习，这个时候你站在的是作者的角度去理解这个设计原理，优点是什么缺点时候，怎么弥补现有的缺点有什么解决方案。相信那些面试的问题简直就是小儿科。无论从现有框架原理、还是数据结构算法、基础的知识你都可以在源码中看到最好的实现，学到最实用的知识。

3 阅读源码的思路

        阅读源码的时候要带着目的去读，这里不仅仅是只了解特性的实现原理。要从带着几个目的去解读一段又一段的源码。

    1 多对比源码中的代码和你平常写的那些不一样，多思考为什么这么写。

    2 多多思考在源码中出现的你平时不常用的知识点、例如 IO、多线程、锁等知识

    3 要经常思考源码中对封装、继承、多态 等特性的应用，比如，类之间的继承，实现、和组合等等特性的应用。参照实现多多实践、多用

   4 从技术或者框架的整体上要参照和思考其领域设计的思路、落地实现、从技术框架上要思考其整体的架构组成和设计架构的出发点。

阅读源码的时候从以上四个方面多问几个为什么用在这里，为什么这么用。阅读源码有目的了，阅读的方式是什么？这里有两种方式：

• 从代码的入口方法去逐层递进

        从代码入口一层一层的扒，这样如果没有目的性或者没有 一个清晰的框架的话很容易迷失在代码的海洋中。所以一定要明白一层一层的跟进的话要从源码中获取到什么。这种方式你可以观察源码的组织方式，从根上了解它是怎么实现的比如，我从入口上开始跟进，我们可以看到他是怎么读区配置文件，怎么实例化，怎么构造上下文环境等等，以及各个环节的执行时机。这种方式方便自己站在开发者的角度去组织代码开发代码。

• 抓住一个特性一条线去查看其实现原理

        这种方式可以方便我们梳理清楚代码某个特性的核心逻辑，和某个特性或场景下的核心算法。相对于整个框架而言你仅仅了解了它的某一块知识，就算你了解很多特性的核心流程，但是没有第一种方式的基础你很难了解他是怎么讲这些特性的核心逻辑合理的组织起来的。

    所以两种方式都需要进行，但是每一种方式都需要知道自己在干什么，要从源码中获取什么。做到有的放矢，获取到自己最需要的东西。

4 总结

        无论你在论坛或者某个专题课或者培训，大量关于源码的东西和讲解，大部分都是跟踪源码、画流程图、解说某个特性的原理。但是我从没有见到过关于某某源码中这段代码为什么这么设计、这个锁为什么用在某某处、某种类继承结构的优缺点和应用场景之类的代码，但是我认为这是阅读源码最精髓的地方。阅读源码像优秀的前辈们学习看起，是为了有一天我们也可以写出同一水平的代码。所以看源码的时候最本质的学习就是要站在作者的角度去考虑问题，考虑设计、架构、实现、应该用什么技术实现等等。只有这样你才能说你看过源码，而不是我画了一堆又一堆的原理图，就说自己精通某个框架或者技术。