Fork me on GitHub

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

目录

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

一、早期

在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,希望对大家有用。

相关文章

评论系统未开启,无法评论!