从一次问题讨论聊聊我对阅读源码的思考

好比本文，没有深度思考的同窗，很容易就被表面现象所迷惑，觉得问题就此解决，立马关掉文章。可是深度思考的同窗就会选择关注肥朝公众号，而后星标置顶，并思考，肥朝为何能迅速找到这个关键的类呢？这个才是最核心的问题！必定要明白什么叫"解决一个问题"和"解决一类问题"！若是你没有掌握分析问题的方法和技巧，下次遇到其余的注解，你仍是解决不了，那又有什么意义？

分析问题

因为肥朝以前写过Dubbo系列的源码解析，公众号也大可能是老粉丝，那么我就以Dubbo为例，说下分析问题的思路。固然这个时候喜欢抬杠的同窗可能就要反驳了，这个问题不是Springboot的吗，和Dubbo有什么关系？我只能说，优秀的代码，套路思想都基本相同，坑爹的代码，却各有各类不一样的坑法。拿Dubbo来分析，并不影响你发现问题的本质！

好比Dubbo中常强调的就是"微核心"、"插件式"。梁飞曾经提过

即然要扩展，扩展点的加载方式，首先要统一， 微核心+插件式，是比较能达到OCP原则的思路，由一个插件生命周期管理容器，构成微核心，核心不包括任何功能，这样能够确保全部功能都能被替换， 而且，框架做者能作到的功能，扩展者也必定要能作到，以保证平等对待第三方， 因此，框架自身的功能也要用插件的方式实现，不能有任何硬编码。

不少同窗看完这段一脸懵逼。其实这段话的后半部分是关键

框架做者能作到的功能，扩展者也必定要能作到，以保证平等对待第三方， 因此，框架自身的功能也要用插件的方式实现，不能有任何硬编码。

因此从这段话肥朝就能够判定，actuator若是要用定时器的功能，他确定站在和普通使用者也就是公众号粉丝使用定时器的角度，去启动这个定时器的功能。

也就是说，spring-boot-starter-actuator中，确定是有类打上了@EnableScheduling注解，而不是零散的调用注解底层封装的一些东西。这个是理论基础。这个理论基础，才能决定你下一步的思考和行动方向。

有了理论基础，那么关键是，到底哪一个类打上了啊！这个时候，咱们能够利用idea的搜索技巧来

idea的这个搜索功能很好用，搜索scope能够设置各类范围，看源码必备技能！

考虑到每一个人的快捷键不一样，所以看下图

敲黑板划重点

看到这里，不少人就容易理解成，本篇是介绍idea的技巧的文章。仍是那句话，看问题必定要深度思考。源码是看不完的，可是解决问题的手段和套路,倒是有限的。不少同窗看源码，就只是看个流程，感受像看电影同样，并无我的的独立思考，这样知识的转换率实在过低。好比你注意看我本文分析的理论基础到实践，这些经验，都是须要你从大量的阅读源码中不断去总结的。

因此，请不要再问肥朝，"看源码，究竟有没有用"，"怎么看源码"等问题，由于我每一篇源码解析，源码实战，都在回答这两个问题，若是你还问这种问题，可见你根本就没有关注肥朝，或者关注了没有星标置顶！

另外，各类源码解析系列（注意肥朝的用词，我说的是系列）还在不断热更中，欢迎持续关注，一块儿"追剧"！

写在最后