{eval=Array;=+count(Array);}
抓住主线,分析源码首先就是宏观上知道这个源码的目的是什么,例如spring就是实现了IOC和DI的功能,概念比较抽象,也可以直接去实践一下,没有spring和有spring写一下创建对象的代码有啥不同,加深对框架的理解,只有清楚了整个框架带来的价值之后,分析源码才能避免“不识庐山真面目” 的尴尬。
区分jar的边界与职责,很多框架都是一堆的jar去不断的集成,我们分析源码首先要宏观的去看待整个框架做了什么事情,然后再分清楚每个jar对应大概做了什么事情,然后这样就能在分析源码的时候尽量不迷路。
抽象思维,对于开源框架来说,其很重要的一个特性就是要把通用需求给稳定化,在此基础上进行迭代,不断的添加最新的特性,在这个过程中保持良好的兼容性与扩展性,这就要求对其他框架采取解耦的方案,保持非入侵的方式。这样带来的代码上的体现就是处处是接口,处处是抽象类,很多方法都是模板方法。这里的行话,就是不要“写死”。依赖抽象而不是实现,这样就可以尽量的松耦合,所以有意识的增强对于接口和抽象类的理解,所以很多人也认为 要比较好的阅读源码首先要熟悉经典设计模式与设计原则等面向对象理论。
底层代码能力,这一块是对于一些偏底层的一些技术实现的熟悉,例如反射,动态代理,字节码植入,或则是范型的使用,函数编程等语法糖的熟悉。当然如果能熟悉JUC包的东西,多线程的理解也非常重要。
带着问题看源码,单纯的阅读的确很容易枯燥,但是我们在使用的过程中,由于前期可能主要关注在如何快速上手可能网上随便搜索入门教程就开始使用后,满足了日常工作需求就没再深入的动力,但是其中某个特性为什么实现,例如mybatis定义的mapper接口没有实现类,是如何注入到spring容器,带着这样的疑问,我们就很自然的产生了好奇心。
画图,图像是比文字更容易加强记忆和理解的东西,语言是后天的,但眼睛是天生的,我们应该善于利用这点,阅读感觉有点混乱的时候就开始进行思维导图的整理,流程图的整理等等,这样的脑图是很有价值的,当然也不要因此打断阅读的连贯性,而是一个大的阶段整理一下即可,每个人的逻辑思维强度会有些不同,可以按需掌握节奏。
犯困就对了,刚开始看不晕才是不正常的,这东西看个大概就行,除非你真需要这一块儿的设计模式,否则就算看懂,不到两天保准儿忘,建议还是会用,而不是上来就研究源码,而且这东西每版源码都不一样看不过来,如果不是在大厂去研发新框架就没啥必要看源码
看一天是不可能看明白的,我看spring源码看了一个星期才开始看明白,坚持了一个多月才看明白容器部分。至于注解部分,我没有空过,仅仅分析过scope注解。注解要看明白,要找到注解的processor,注解本身并没有什么内容。找到Processor,才能知道注解的真相。
其实直接看源码就是比较让人难以琢磨的,因为很多时候源码的底层是计算机深层技术,和
表面看到的逻辑是不大一样的,源码分析,可以从某一个技术点来看,自己看纯理论的说明
的话,倒不如看一些图例分析或者视频讲解来得更明了一些,只要是大白话一些能给你举几
个现实的事物比较,就更加形象啦,比如说一个bean实例的创建过程,可以看看这篇文章,
https://m.toutiaocdn.com/i6745978831934325260/?app=news_article×tamp=1593417076&use_new_style=1&req_id=202006291551150101300371352404BFFB&group_id=6745978831934325260
看看不同时期做的具体操作和为什么这样的做,源码的底层一般效率都是比较高的,尤其
这种设计风格,在以后自己的代码风格中可以多多借鉴! 就像通信技术,简单地看一个短连接和长连接的区别,以及这样做的优缺点,加以分析和比较![呲牙][呲牙][呲牙]
带着问题去看代码,为了解决问题去看代码,如果不是为了具体的开发目标,而是为了提高技术水平,应该按教程学习或自己开发开源软件。 这类似于学习语言,放到 这个语言的环境下,经过一段时间,无意识就学会了。而想考高分而突击背单词,肯定一背就犯困。就比如这个问题,transaction 你看懂后,是要修改transaction 哪部分功能? 到达什么目的,先把这些想清楚
10
回答0
回答0
回答0
回答2
回答0
回答0
回答0
回答0
回答0
回答