我已经从事了Java软件开发已经有8年了，但总是感觉自己还“很水很水”，根本没有底气去写一个软件，甚至感觉自己连Java都没学好。按道理来说，工作了这么长时间，应该会有一点点牛气了吧，可惜真没有啊。
如果分析一下这些年来的个人发展，其实也不难发现问题的原因。其一，客观原因是平时的工作都基本把全部的时间都丢在了公司业务开发上了，其余时间虽然自己也尽量用于自我增值，但却学习的方向有点杂，不管啥都学，前端学，后端学，运维技术学，甚至连linux系统原理也想去深究，学习面是有了，却深度不足，连最重要的Java饭碗都没抓牢。其二，并不是自己没尝试过去深入学习Java，也尝试过去研习各种名框架的源码，以此来提升自己，可是，每次面对如海般深不见底的代码逻辑令人忘而生畏。其三，由于是半路出家的技术，对系统原理的理解不足，也不够深入，而Java是上层应用，在使用上面就会有树没了根一样的感觉了。
在这个中年危机的时间节点上，我的确有些害怕，但又不想把多年的努力付之东流，我还想给自己一个机会，以分析Spring源码作为启程，好好地努力一把，不至于在这人才浩荡的互联网时代被清洗吧。
Spring源代码分析方法
对于如何分析Spring源码，网上有各种的评论，大多数都并不建议进行细读，细读Spring源码至少要花N年这样子危言耸听，只要了解其原理就够了的言论。但我并不是这么认为。发表这些言论的只能是搬砖程序员，这样的人与农民工无异。农民工永远只懂得使用工具并按设计师的图纸进行房屋建设！农民工与设计师的区别是他们往往缺乏思想，缺乏深层次的知识基础。 因此，只会使用大师们设计出来的框架（好比设计师的图纸）进行开发，最终只会导致我们只能成为熟练的农民工，永远成不了设计师的。借着阅读著名框架源码过程，分析代码中使用的设计模式，看看大师级人物是如何编码的，分析代码中所蕴含的思想，去了解代码编写的艺术，从中吸取精华以指导日后的编码工作，其实是一条指引我们从农民工走向设计师的捷径。
网上的评论也并没有说错，要细读一个框架是相当花时间的。如何才能高效地对框架源码进行分析呢？
最近两周都在分析Spring的源码，对如何细读Java源码也有一点点心得了。其实在分析一个框架源码就好比去认识一个发动机的原理，我们不可能只看发动机的外观来分析，而是需要把发动机拆散成一个个零部件，先对各个零部件的原理进行分析，如齿轮，齿比，火塞，曲柄等等，每个零部件都有其功用和特点，当清晰了解每个零部件的原理之后，再把零部件组合成一个整体去分析，就容易理解得多了。
从分析发动机原理的过程中可以得到启示，如果要分析一个框架的源码。
首先第一步要做的是——拆：
我们可以通过调试的手段，跟踪代码的执行流程，把执行流程中的关键组件找出来（通常这些关键的组件会由一个核心接口进行声明）。这就是一个拆的过程。
第二步要做的是——关键组件的分析：
关键组件往往不会只由一个接口组成，而是由多个接口组合而成。因此在分析关键组件的时候还可以继续拆分，拆分可以把这个组件的接口继承关系通过类图的形式表达出来，然后对每个继承关系下的接口进行分析，这时就可以通过接口声明的方法及接口的注释说明去理清接口的职责。当清晰每个接口的职责之后，就可以去猜想框架是如何实现该关键组件的了。然后伴着自己的猜想去细读源码，看看是否与自己的猜想相同。
第三步要做的就是——整合关键组件：
整合关键组件其实就是按框架的关键流程去分析源码，看看框架是如何把第二步拆分出来的关键组件有机整合起来的了。
基于以上对源码的分析方法，对Spring框架的分析过程也会按关键组件分篇章进行，之后才对Spring的核心功能（如IOC，AOP)进行分析。
关键组件分析的章节结构
- 概述——简要描述关键组件在Spring框架中的作用，对将要分析的组件有一个感性的认识。
- 组件的继承关系类图，类图需要标出接口的方法、接口方法的参数，接口的注释，用图形来表达作者的设计意图。
- 对类图中的接口进行更详细的说明。
- 组件的实现分析，需要指出组件实现的关键点，包括难以理解的点，核心实现逻辑，以及这样设计所使用的思想。
- 如果可以，分析一下组件如此设计的优缺点。
- 贴出组件的用例代码，指出组件的使用方法。