分享：个人是怎么学习新知识的

挺多童鞋问我是怎么学习新知识的，干脆写篇文章总结一下，希望对大家有所帮助。对照书、技术博客、极客时间等学习的方式我就不说了。

一、早期

在15年及更早，由于知识储备少，基础偏弱，大致采取了如下的步骤：

1.1 入门：找教学视频

了解xx是什么，能解决什么问题。例如个人学习Spring、Struts、Hibernate时，就是找了 马士兵 老师的视频。

值得一提的是，记笔记非常重要，一是可以形成相对完整的知识体系，二来也能应对面试——面试之前花点时间看看笔记就能很快记忆唤醒。 个人原创学习笔记可关注公众号“IT牧场”，点击 资源领取 即可获得。

1.2 实战：模拟项目

俗话说，学以致用，为学而学是没有意义的——即使有意义，过段时间也会遗忘。所以个人在掌握基础知识点以及常见用法后，一般都会做个简单的项目。作用主要有几点：

• 巩固知识点
• 总结最佳实践
• 锻炼自己的产品思维

从15年起，个人每年都会定”做一个 Side Project “的KPI——这个项目能承载如上三点作用即可。

• 15年：基于当时的主流框架捣鼓的快速开发脚手架 Platform（选型较老，已被时代抛弃） ；
• 16年：基于Spring Boot的半成品 CMS （起因是来了个私活儿，于是开工，后来合作崩了，就废弃了）；
• 17年：基于Spring Cloud的快速开发脚手架与最佳实践总结 Spring Cloud YES ，现已升级到Spring Cloud Greenwich SR1版本；
• 18年：微信小程序 IT牧场 ，在公众号导航栏点击”资源领取”即可进入，近期开源。

顺便说下，这些项目的内核基本一样，但每次又有优化——每次拷贝老代码前，都再思考一下，看有没有改进的空间——这不是正是”重构”？既是对自己过去代码的重构，也是对自己技术的重新审视。

二、15年后

15年后，由于工作好几年了，知识面、知识深度都达到一定程度——特别是15年初自学Hadoop以及Spark后。

一点趣闻

学习Hadoop和Spark的契机：当时大数据很火，工资很高，于是面向工资编程，想转型大数据。当时正好所在公司高层变动非常频繁，大佬们都忙着政治斗争——倒是爽了我这种小技术经理以及开发兄弟，整整一个半月，没有任何需求。于是投入全日制投入学习，偶尔改改bug。

后来发现，学习Hadoop和Spark是个笑话——因为学完发现在南京找不到大数据岗位——

• 面试中兴，技术通过了，开17K，部长面也过了，结果卡在学习，说民办本二算本三，不符合他们的学历要求，我也是醉了。
• 面试鸿信：对方说自己有1T数据，规模在南京排前三。我嘴上不说心里想1T算个毛的大数据……

后来又继续搞Web了。但学习还是有好处的——

• 大数据知识点杂，有时候还涉及不同语言……这锻炼了自己的知识整合能力；
• Hadoop、Spark本身普遍是分布式应用，这为后来玩微服务打下很好的基础；
• 很多时候，知识点是相通的，如果能探索到本质，会发现很多所谓高大上的东西其实也就是那么回事。

此时，我觉得看视频入门效率太低了，所以调整了下节奏：

2.1 入门：GitHub Demo

看教学视频固然是个很好的方法——因为学习曲线足够低，而且会有导师告诉你怎么用，甚至给你总结好最佳实践。但多数情况下，视频教程对于这个阶段的我，效率已经偏低了。很多视频几十分钟才讲一两个知识点…即使倍速，依然感觉在浪费时间。

于是我采取了Demo驱动的方式学习。以学习 Spring Boot 为例，Spring Boot官方提供了 Spring Boot Samples ，把代码clone下来玩一遍，就能相对系统得了解Spring Boot提供的能力。

TIPS

并非完全放弃教学视频，学习途径的选择是多样的，有时候是二选一，有时是两者配合。

只是进入这个阶段后，个人GitHub Demo驱动相对用得相对更多一些。建议大家做个简单的评估，怎么快怎么来。

2.2 系统学习：官方文档

Demo驱动入门后，我一般会对照官方文档撸一遍，例如学习Spring Cloud时，我把官方文档中的用例都过了一遍。

官方文档带来的好处如下：

• 一手文档——官方文档永远是最好的文档，书、视频等等本质也是别人通过学习官方文档进行二次创作的；
• 能体会官方的意图
• 感知该软件的发展趋势(例如阅读Release Log)
• 系统、详尽。

很多人可能觉得自己英文水平欠缺，不敢阅读英文文档，这点我只能说硬着头皮上吧，其实坚持一段时间后，你会发现也就那么回事。大部分英文文档还是比较通俗易懂的——再者，现在谷歌翻译质量非常高，进一步降低了阅读英文文档的难度。

我的 Kubernetes开源书 ，本质就是官方文档翻译(一般看一边翻译) + 个人理解 + 批注。

总的来说，IT行业人才分布也是符合二八定律的——80%的普通人，20%的高手；20%高手里面，80%的普通高手，20%的大佬。我觉得英文不好不是借口，主要还是看你想成为哪个20%——付出和回报是成一定比例的。

另外还有10000小时理论，也可以给大家共勉——要想成为某一领域的精英，必须在这一领域深耕10000小时——如果连英文文档都不敢去碰，怎么可能成为精英？

大道理大家都懂，不再废话了。

闲话

13年个人定了一个原则，就是不找客观借口。因为客观借口只要想找，永远可以找100个。失败是客观事实，但很多失败都是由于主观因素导致的。失败就是失败，首先要有勇气直面。如果连尝试都不敢，就失败了，那真的是可耻到极致的失败。

进入阿里后，我的思想再次发生变化。以前有时候我会觉得由于我没有xx资源，所以我做不了xx事；但现在，我的思想变成因为我要做xx事，所以我需要xx资源，如果没有，那我就去争取；如果没有那我就想办法抢。我离成功还很远，但我会继续努力。技术上成功的难度，对我来说相对低一些，所以我坚持技术路线。

2.3 实战：模拟项目

和之前一样，还是做个简单的项目玩玩，项目能起到练手的目的即可。

2.4 深入：带着问题分析源码

起源于在 焦点科技 的一场面试——焦点科技面试官是对我职业生涯中造成影响的面试官，虽然只有一面之缘，甚至连对方的名字也不知道。

与其说是面试，倒不如说是”切磋”——一般面试，往往是你问我答，OK，NEXT。回答对不对，到不到位，往往不会揭晓答案。

这位面试官很有意思，他会从一个简单的问题逐步深入，并且如果回答不上来，对方会给你很多提示，就像武侠片里师父给徒弟喂招一样——这样面试下来会有所收获，也会了解自己欠缺的地方；更好玩的是，如果你聊到对方不了解的地方，也会问到他懂为止——这其实是考察候选人的沟通能力的常见手法之一，但目前业界又有多少面试官能做到呢？

这次面试给我的启发是：如果广度已经很好，是不是应该深挖呢？

深入，最好的方式就是阅读代码。而为了看代码而看代码，在我看来是浪费生命、浪费时间。所以，我选择在遇到问题时，带着问题分析源码——这里的遇到问题，并不是代码运行报错，或者是项目出异常；而是指对xxx感到好奇，想要了解原理，于是带着问题阅读代码。

2.5 广度：跟进业界动态

个人比较喜欢看科技新闻，大学开始，常年在煎蛋、CNBeta、36氪等科技站上潜水。然而，从15年开始，就一直在995/996，跳到哪儿哪儿加班……时间不够用，必须做出取舍。

经过分析，发现开源动态对自己更有价值。于是坚持每天花10-15分钟刷开源中国的”软件更新咨询”栏目——软件更新栏目相信很多人有所了解，其实就是某某开源软件又发布了新版本的新闻列表。

然而，长期关注至少能获得如下几点信息：

• 咦？xx软件发布了，这个是啥？解决什么问题的？
• 咦？xx软件又发布了，这玩意儿挺活跃啊！
• 咦？xx评论挺多的，看来很快会流行起来。

长期关注的收益：

• 了解行业动态
• 增进知识广度
• 培养行业敏感性

我在15年玩Spring Cloud、16年玩Docker、17年玩Kubernetes，时间基本都在业界流行之前。之所以有这种行业敏感性，和长期刷开源中国是分不开的。

TIPS

再安利就变成开源中国软文了……相信我，开源中国没有给我钱……

三、16年后

3.1 写博客：让别人也能懂

16年，因为一些契机，从开发转型成为架构师。角色的转变，带来的是思考视角的转变。之前做技术经理时，名下只有四五个人，多数问题口头交流就OK了；但成为架构师后，负责的面变大了，有时得和几十个人沟通，而很多沟通是重复的。

此时，我意识到，不如把大家常见问题总结总结，写成手把手的文档——

• 手把手上手系列
• 手把手解决问题系列
• 血的教训系列……

再后来，发现写Spring Cloud开源书、博客、实体书……

写作本身也是总结的过程，而且不仅要自己懂，还要想办法让别人也能看懂。

可能是写手把手系列多了，所以我的文章一直也是手把手、附具体步骤、配详细代码，原理、源码分析写得相对少一些，这点也被一些人诟病。个人对博客的定位，主要是引导新手，其次是个人心得总结。如果人家已经入门了，还需要到处找文章吗？自己研究研究就OK了。

那些喜欢看源码解读的”高手”，有多少是真高手，有多少是伪高手？我相信有源码阅读经验的，都不会觉得阅读源码是一件高大上的事情——多数情况下，看懂开源软件源码真的比看懂你所在项目的遗留代码简单多了！

趣闻

18年在华为面试 ，和面试官聊到Zuul相关源码。大致问题是：聊聊Zuul ErrorFilter存在的Bug。这个Bug其实在Camden已经修复了，但是我好说歹说面试官都不信。结果再一打听，原来面试官看到《Spring Cloud微服务实战》是这么写的——这本著作是基于Spring Cloud Brixton撰写的，该版本确实有Bug，所以作者非常贴心地给出了解决方案，却被这位面试官拿来做考察一个人对Spring Cloud是否深入的尺子。

四、写在最后

以上是我历年学习方法的分享。其实总结起来就一句话：我不够聪明，但我会死磕，逐步积累；我不找客观原因，硬上。

中间穿插了很多例子，文章可能有点碎……Anyway，希望对大家有用。