学习的方法
引用两句话：
我想更深入的探讨一个系统的设计是被什么现实和本质问题所逼迫的结果
从乱糟糟的观察到的混乱表象中，抽象出流系统所面对的问题和解决方案的本质
文章连接
珍惜遇到的每一个难题
系统的好坏与否的一个本质问题：是否能尽可能的分析出系统所面临的边界条件。边界条件越多的系统，复杂性也越高。
在整个技术体系里，大致可以把常用的工具分为三类：
- 语言
| 语言 | 是否编译 | 性能 |
|---|---|---|
| Java | 半编译 | 中 |
| Go | 编译 | 中高 |
| Python | 解释 | 低 |
| Php | 解释 | 低 |
| C++／C | 编译 | 高 |
数据库
维度：行列、分布式、性能高低、消息队列、缓存。常用组件有 mysql，hbase，clickhouse，hive，kylin，kafka，redis。计算框架
维度：流处理、批处理。常用组件有 Flink，Storm，Spark，MapReduce。
在实际工作中，接触到的东西远不止上面列出的，还会有各种各样的框架和技术概念，例如：spring、spring cloud、djano、yii、tensorflow、微服务的各种框架。而技术框架又是在不停的推陈出新的，做为一个工程师，如果不持续的去学习新东西，可能很快就会被淘汰。这也造成了我们一直在疲于奔命的现象。
我的日常工作中，接触过很多种的工作，后台管理系统、后端服务、微服务、OLAP系统、流计算。每种方向用到的框架都不同，而且每种方向都有很多框架。满足工作需求很简单，看看demo，文档基本就能开始工作。
如果长久下来只是流于表面，对个人成长基本上是没有帮助的。
个人根本是没有任何收获的，非常容易被替代掉.
如果只是知道这个工具怎么用，一个新人花点时间也就能学会，老人相比于新人也就没什么大的价值了。沉淀很少
如果用到的框架被另外一种替代了，或者更新了。该何去何从？是要重新学习新框架呢，还是要重新学习呢。
因为这么些原因，我时常有这些疑惑:
- 为什么要有这么多框架
- 两个组件功能相似，一个已经流行了，为什么另外一个还能流行起来甚至替代原先的框架
- 这些现象背后的根本原因是什么？
在有了上面的疑惑之后，我又抽象出来了一些问题：
- 一个系统要解决的本质问题是什么？
- 它是基于什么样的理论被创造出来的?
- 这类系统相关的边界问题是啥？
- 两个系统是在哪个点上差生分叉的，不得不分叉的理由是什么
- 理论和实践的关系
我把解决这些问题看作解数学题的过程。我们平常做的数学题可以看做是一个个系统，而公式可以看做是这些系统背后的理论。
先找资料，找不到看源码。
技术深度是非常重要的，在最常用的技术上深度是非常重要的，例如操作系统、网络、JVM调优。但是当承担的任务大了的时候，广度就会变得更重要一些。
做技术选型时，就需要首先技术广度足够才可以，可以清楚的知道每种中间件的用途、主要应用场景，还有业务未来的发展方向，综合下来才可以选定当前业务的技术栈。
个人精力是有限的，而各种中间件、框架又是在快速的迭代发展，很难把每种中间件、框架都研究透彻的。面对这种情况，我认为一个人最核心的能力应该是如何将看起来复杂的问题进行抽象。在知道如何抽象之后，一个方针来去指导如何学习，以及怎么才能快速的摸清一个中间件是否满足需求，并且在遇到问题时如何快速定位。
构建知识体系，本质是对所学知识的抽象的一个过程。剥离所学知识的表象，找到其本质，追根朔源，了解理论／技术产生的北京，要解决的问题，各个知识点之间的关系，理解其脉络，才能灵活运用。
理论的变化是非常缓慢的，基于理论的实践而产生的事务是非常多变的。
类似的软件基于同一理论，又在某个功能上产生分叉。理论上不可行，但在工程实践中又宣称实现了这一理论必定做了某种折衷，理解一个框架就要理解清楚其背后的理论依据。从理论出发，可以摸透一个软件的脉络，它折衷的地方在哪，可以提出优化方向，洞见某个领域的发展，跟上时代的潮流，甚至走在领域的前沿。