一. 人生就是不断学习和探索的过程

前几天看到一篇文章——《做一件事如何突破「擅长」达到「精通」》(这儿还有一篇)，我却想到写这篇如何快速入门一个全新的陌生的知识领域的经验文章。
这种不断浅尝不止的学习经历，没有帮我成为某个领域的专家，但是却帮助我对学习新东西大大降低恐惧之心，而且充满乐趣。入门的短暂，也领略到另一扇门后的风情，以后，倘使可以沉静下来，也比重新开始的人更加节省时间。且，闲着也是闲着，干嘛不去学点新东西呢?

接下来看你想在什么方向投入足够多的时间，如果没有时间，也暂时不要苛责自己，毕竟，人生还长，到了以后，想要捡也来得及。

二. 个人的快速学习经验之谈

那么，如何能够快速进入一个全新的知识领域呢?四部曲：

1. 大量泛读：

目标：扩大信息源，兼听则明

关键动作：搜索、查看相关书目、记录关键术语和概念、收藏一些精品文章待重复阅读

要点：开放吸纳，不做判断，不强迫自己记忆

扩大信息源，搜索，查找，开放吸纳，不做判断，做大量的泛读，不争取全部理解。在这个过程中：适当保存一些你认为可再次精读的文章，但是目前阶段，先不要把重点放到精读上。我们的目标是：先让大脑爆炸掉。

2. 整理核心术语并梳理关系

目标：建立知识框架体系

关键动作：回顾术语，适当精读，明确术语之间关系

要点：可视化，讲故事

4-5个小时泛读之后，我们已经有一个很大的突破：我们已经拥有了一个全新的知识领域的各种术语了。当别人提出，你最起码知道他们在说什么，也能够恰好联想到这个术语之前所存在的信息，大概是什么场景，基本的交流应该已经不成问题了。

但是，真正的化学反应应该在之后发生：——找关系

关系是一个很有用处的概念。古人云的“举一反三”，本身就是要依赖于关系。这个“一”和“三”所代表的“事物”，一定是有某种相似性、相关性，才能够让我们举一反三。

但是，明晓“关系”本身就是一个非常高深的技能，不然就不会有一句话：“物有本末，事有终始。知所先后，则近道矣”了——突然觉得得道的人都是关系学家，他们都是掌握了种种关系之要诀。

关系的分类很多，比如因果(因为a所以b)、依赖或影响(有了a，b会怎么样)、次序(先做a再做b)、相似(a和b在某些特指的属性上同类)、相近(a和b在空间或时间等维度上接近)……，如果我们搞不清楚，那么就是统称“相关”，大家可以理解为什么新闻里经常出现相关这个概念了吧。

我们拥有的术语，当然一定都是“相关”关系，我们的任务恰恰就是把这些“相关”进一步明确掉。

Step1. 卡片分类，建立属性层级分类

可以用脑图、站点架构图帮助我们快速梳理。

这块可以帮我们更加抽象去理解这个复杂的系统，而不是聚焦在具体某个特例上，也是举一反三的基础的基础。比如，当你知道了PHP是做什么的，而你又了解了JAVA、C和PHP经常在一起对比，他们都属于开发语言，那么在这个阶段，你不需要深入学习某种语言，只要把术语中属于开发语言的都放到一个坑里即可。

Step2. 可视化它们的关系

即使我们已经对这些术语分好了类，简化了我们的理解，但是他们彼此间是如何发生关系的呢?

除了重复阅读加深理解外，单纯的文字表达已经比较苍白了，我们有必要借助一些可视化手段帮助我们快速理解整个知识体系。

脑图(MindMap)：

侧重于描述层次关系——从高层到细节的发散。脑图要表达的关系非常单纯，可以说是最不需要动脑子的图，只要有基本的心智，加上一个工具(现在这个工具也被破解得很厉害)，分分钟产出一份看似很高大上的图来。所以大多数人都很喜欢用它，尤其是老板，组织架构用它，梳理需求用它，提功能清单还用它……

不动脑为啥用脑图呢，可能是脑图本身也是定位于将你大脑里原原本本的东西给掏出来有条理展示出现而已。

这个图，我都懒得上例子了，自己搜去。

流程图(FlowChart)：

这个图就需要动点脑子了，梳理流程本身还好说，把事情给还原出来，关键是流程优化也要靠它。流程图根据表现形式，可以分成普通流程图(好吧，我承认这个术语是我自己造的……人家也不知道怎么叫嘛)以及泳道图。依据使用场景，则可分成业务流程图、数据流程图、页面流程图……

具体的，我之前也写过一篇拙文，如果有兴趣的话，也可以继续去拍拍砖。

架构图：

现在我画得最多的，而且觉得需要好好学习的，就是架构图。但是这个图很神奇，没有对错，没有办法去评估，甚至还没找到一定的绘图标准。请教一些技术架构的牛人，得到的就是这种图要体现系统最高层次的划分以及各部分的依赖关系以及系统与外部的关系。自己看了网上的一些架构图，发现也确实没有一定的规则。所以只能慢慢感悟了。

但是我个人真的有个强迫症：这世界上怎么会存在讲不清道不明的技能和知识呢?只要存在，一定有潜在的规则和方法(甚至可以分解成具体步骤的)，只是还没有被很好总结出来而已。

架构图举例：

因为架构图能够既清晰表达层次划分、大的模块的分类，又能够很好表达他们之间的错综复杂的关系(其实更多就是依赖、引用、数据流向等关系)，所以经常被演绎成“生态图”，比如移动互联网生态图：

关系图：

这样的图你大概在网上经常见吧?

不得不承认，这样的表达，确实比成段的问题要清楚多了不是，如果你搜“关系图”的话，出现最多的就是这种应用场景了。此外就是在计算机领域的“实体关系图”-也即E-R图，也是我学习内容之一。但是因为关系图的关系本身概念更加广阔，所以不管任何关系，其实都是可以叫做关系图的。

如果架构图再进行简化，到一个个实体之间的关系层面，则可视为关系图。而通常说的概念图，从狭义的层面，也是一种关系图，从广义的层面，则无所不包了，哪怕你随手勾勒一个简笔画，用来描述你想要的产品，也是一种概念图了。

说到底，掌握画图的核心：在于表达关系。其实我们可以不拘泥于这些图的分类，你只要有基本的图形、线条、合适的工具，那么就可以开始了。

此外，讲故事，也可以在画图之外，有助于我们理解，比如当时我的一个牛掰同事Justin，就是这样给我们普及了下网站基础架构知识：

Apache：服务器。APACHE好比是饭店的服务员, 你告诉他给我上个八抓鱼, 他就给你弄个八抓鱼.你说: 我要熊心豹子胆!他说:”对不起, 您要的菜不存在”服务员还能根据特定的菜来做跳转.例如,规定, 凡是要熊心豹子胆的, 就给他上盘老鼠药.这服务员很厉害他能把所有用户点的菜, 都记录下来能根据菜量和品种的不同, 找到特定的厨师.能把不受欢迎的顾客拒之门外.

Java：厨师。JAVA是对请求做出相应处理, 取出数据, 加工数据, 返回结果。服务员说要红烧猪蹄. 那么厨师就从向配菜员要猪蹄, 然后炒巴炒巴就做好了, 交给服务员.只要有材料, 厨师几乎是什么都能做. 但是厨师是有快慢好坏之分的.有的又快又好, 有的又慢又烂。这样可以理解其他的开发语言，都有类似的属性。

数据库：数据库就是一个配菜员加一个大冰箱。是存储数据, 各种数据处理工具的一个东东，厨师(java)说要个20个10斤重的白萝卜, 配菜员就从冰箱里找出来,再给厨师.

缓存：把经常要用到的配菜和原料在厨师旁边留一些备用，免得每次都要去数据库要数据。有些是一直要放到厨师身边，叫做本地缓存，但是厨师身边的空间是有限的，所以还需要远程缓存，这样即使多走一些路，也不至于每次都要麻烦配菜师取菜。

……

这样，再配合他提供的网站技术架构图，非常形象不是吗?

3. 验证

当你梳理了术语，并能够能通顺地讲、可视化他们之间的关系的时候，其实我觉得你应该已经入门了。

但是你的理解是否是对的?或者你在过程中，一定也会遇到疑惑和理解障碍。

将这些问题，记录下来，然后再重新进行一些针对性的精读，效果比一开始精读的好太多了。因为：

你带着问题去读，一定会有更多思考，变被动的接收成为与作者的交互

你有了一定的知和理解基础

到这个阶段，如果还遇到一些无法解答的问题，那么询问更为资深的人物获得帮助，另外，也不必对他们的回答全盘接受。当你已经有了一些基础，你也会发现，或者这些“专家”给出的答案，也仅仅是一种可能性、一种场景而已。或者是他自己的很好的经验，但是是否能够被你所用，则要具体情况具体分析了。

4. 计划

知识体系有了，你在全图之下更易取舍：哪些要继续深入学习，哪些是你将来工作必不可少的，哪些仅限于目前的了解即可……

比如在了解了数据产品构建过程中，发现数据仓库、数据etl、数据挖掘是仅限于了解的，而数据应用层的数据可视化，以及报表系统是可以结合过去的背景更好发力的，那么就深入之。

取舍后，就可以制定具体的精进计划。

最后：甘于做门外汉乐于做一些门的门外汉，偶尔透过门缝窥一下里面的风光。