程序员总是容易焦虑
程序员很容易焦虑， 有来自外部的压力，也有来自自身渴望快速成长的急促感。
作为一个程序员，我们一般关注了很多公众号、博客，每天时不时的看到 “大牛们” 解决这个大难题、研究那个源码，就赶紧是在碎片时间 “跟随” 其脚步阅读了其短篇，暂时得到了满足感 -- “嗯，又学到了xxx” 但是没过多久，由于对其问题的知识背景等的缺乏，连基本的印象都没有，更别说有什么共鸣然后在自己的实际工作中起到引导修正作用了。当然，我不是说不要去关注牛人们的分享。
还有，新的编程语言层出不穷，各种框架大放异彩。 比如说，前两年 node 突然火起来了，node 工程师的价码一年就达到多少多少，要不要趁人还不多的时候先入行？然后后面也算是资深人士了； 更有甚者，在上海你可以看到，突然好像 .net 的大厂都转向了 java 体系，其原因可能很多，有可能是 java 开源生态太舒服了非常适合浮躁的互联网行业快速选型，而且也有大厂背书各种解决方案，也或许是对微软搞开源是否给力的担忧。咱不管这个，对小码农来说更直接面对的可能是公司新招一批 java 体系的人，一开始业务不熟悉要原有人员带着，技术嘛 可能就是一直干 java 的，但是薪资、职级等高上一大截（公司就是这么无情）。那这些人怎么办？ 老实呆这里吧，估计又有些不舒服，再去外面找这个方向的又好像都是中小企业了；转 java 再直接去外边面试？这又会遇到知识体系的积累问题，再简单的知识都需要时间来积累，而其他公司（内推除外）招人还是会按照该方向的知识体系来鉴别。这就非常尴尬了。这边也有可能是公司大佬拍板要从一个方向转成另一个技能体系造成。
至于每个人内心对成长的渴望（我家主子现在吃的就是叫“渴望”的猫粮， 哈哈）这点， 可能是由于在公司负责的业务系统所接触到的技术没那么“高大上”， qq群里都在讨论着什么什么框架，自己公司却不用，或是研发经理分析下来没有必要搞那么复杂。自己去学吧，没有实际项目去踩坑有些东西没那么深刻，而且还要花更多业余时间。
我们需要的是确实的提升自己
其实别人再牛逼和你又有什么关系呢？我们需要的是自己一步一个脚印的走，成为拥有实打实的知识体系、技能实践和业务解决的能力。
在公司上班，需要用一种技术体系。 我们会需要熟悉一个主编程语言的语法、常用的工具包、开发工具、然后慢慢深入原理以更好的分析问题。 这些都是要自己慢慢地系统的撸的。
还有是怎么提高干活效率，比如我一直在做业务系统， 随着对一个业务的了解可以慢慢梳理出一些固定的流程模型，抽出抽象类来固化特定的代码逻辑，然后子类实现不同的处理；也有一些策略呀，责任链模式等的应用； 或者是物理上直接拆成小的服务。 但是对代码的抽象、模式的应用、应对鬼画符的需求能力有没有更好的方式？ 我要怎么提升这方面？ 源码，特别的基础类的框架源码，经过了那么多人的使用，提高了那么多人的开发效率，满足那么多的需求，它是怎么做到那么灵活可扩展的？
我们自己学习或是准备面试的时候，会去完整的撸一下二十几个设计模式，其 uml 图、 demo 代码、相似模式之间的对比，然而在实际用的时候，是不是有时候还会感觉还是有那么点卡顿？ 可能是 SOLID 基本的原则没有太透，也可能是没有看到实际应用中解决了什么问题，带来了什么方便（非demo），这时候，框架源码也是很好的材料（毕竟，大神写的代码）。
虽然，网上有很多人已经读完某某源码了，但是人家也不是一朝一夕就完成的；关键还是我们自己在这个过程中思考、领悟后带给自己的提升。一定要自己去做、自己思考才算自己的。
不要太过着急， 吃下去的鸡排才是自己的嘛，光闻着香肚子只会更饿。
总之，
静下心来
慢慢沉淀
最后，个人阅读spring源码的期望目标
- 核心模块的设计思路和实现
- 设计模式和其在框架里边解决了什么问题
- 集成其他开源工具的方式，然后又是怎样提供一致风格的api
- 基于核心模块的应用模块
