《如何快速且深入的学习一门新技术》读后感

本文是学习颜群的《如何快速且深入的学习一门技术》的一篇记录文章,对方的很多观点和让我很受启发,虽然自己平时对学习方法有些心得,但是真正去总结自己的学习方法却很少。缺少盘点的结果就是任凭本能和学习状态,显然这种方法是不可持续的。为了提升个人或团队的学习效率,如何摸索一套针对技术类型的学习方法是非常值得每个技术人员去探索和总结的。

  软件开发正处于快速发展的时代,新技术层出不穷,那么在这个日新月异的互联网时代作为软件开发者,我们应该如何保证自己的技术竞争力?我们今天就来聊一聊,如何快速且深入的学习一门新技术。

观其大略

  大家可能都知道,英语考试里面有一个经典的题目叫"完形填空",老师经常告诉我们,在做完形填空之前,一定要先花一分钟的时间,整篇文章快速的阅读一下,对整篇文章有一个大致的了解之后,如果再去做题,准确率就会提高很多,那我认为这种做完形填空的方法也应该同样适用于软件学习。

  我们在学习某一个软件新技术,也应该先快速的去浏览一下这个新技术的主要大致情况之后,再去研究每个新技术里边到底包含了哪些技术细节,遵循从整体到深入的过程。

找出套路

  各种技术都有自己的模板结构:

  • HTML:代码结构固定
  • Netty:代码流程类似
  • JDBC:实现步骤固定

  不论是前端还是后端框架,这些技术都有一个共同的特点,就是他们有一定的套路可遵循,因此我认为一个比较好的学习方法应该是先不管三七二十一,先快速的去了解一下具体的套路到底是什么,然后再去深入研究套路里面的每一步到底是什么,那这样才能高效的学习一门新技术。

  那么如何了解套路呢?

  在学习新有之前我们一定得先宏观的全局性地快速地了解一下技术的全貌,那这样才能清晰的认识一下,技术里边哪些是套路,哪些是重点,那么这是你可能会继续问,到底应该如何的快速阅读技术的全貌呢?

  这其实是快速阅读理论知识了,推荐大家可以以快速的跳跃性的方式来查阅一些资料,来看一下执行流程是怎样的,具体细节你可以查阅技术官网,看书看博客或看一些视频教程的。重点要看这些教程里边反复出现的重复代码,一般而言那些频繁出现的重复代码就是这个新技术的技术代码结构了。

总结

如何快速寻找新技术的代码结构:

  • 快速、跳跃查询资料(官网,看书,博客,视频)
  • 出现频率较多的重复代码。

这种方法虽然自己了解,但是平时应用并不多,没有刻意练习,更没有形成本能的习惯。这种方法看似囫囵吞枣,其实从效果来看是非常科学的。高屋建瓴,快速的在脑中创建全景图,有了模糊的知识树导航,对后续的深入学习也好,耗费的时间成本也好,都会有一个初印象,一定程度上可以消除对新技术的陌生感和恐惧感。

既然是深入学习,到后期观其大略应该是不够的,脑图好比地图,如果不能深刻印在脑子里,实战必然无法做到熟练使用,如何能说是深入学习呢?

所以前期观其大略,后期必然是烂熟于心。比如学习k8s,你如果不能很清楚的了解其中的7个大的组件用途和关联,那么在运维和开发过程必然会不自信。

深度学习

  技术初体验仅仅只能算一个入门程序,要想真正的掌握,必然还得进行深入的学习,那该怎么深入呢?

  我认为通过案例来倒逼对理论的理解应该是一个比较好的方法,比如Netty案例库的学习。按照下面步骤搭建完毕之后,我对他的掌握就已经很熟悉了。

  

  • 第1步,通过快速学习两个小时,了解了Netty的整体流程
  • 第2步,从初体验的hello world开始,逐步积累Netty的案例库
  • 第3步,当案例搭建完成,大脑已经建立了对Netty的思维框架图

深度学习并不容易,这是一个打怪升级的迭代过程,中间必然会因为细节栽倒,从坑里爬起来返回理论,再返回实践验证。这里与其说是深度学习,不如说是对毅力的考验,如果在韧劲上能加上一点兴趣,遇到问题的心态能够更加放松,并乐于挑战,那么这个阶段,估计会倒下一大批同学。

强化学习

  相信通过前面的讲解,你已经清楚的知道如何快速掌握一门新技术,但是现在还有两个重要问题需要解决:

  • 一个是对知识的掌握足够吗?
  • 另一个是刚才学到的新技术会不会很快忘掉?

  这里我建议一个方式就是做微服务案例,通过案例来滚动整合先前的技术。我们可以先用每一个技术搭建一个独立的服务,然后再把由不同技术搭建的微服务整合起来。

  

  举个例子,当你学完ssh的时候,就用ssh搭建一个用户管理的服务,学完ssm的时候就用ssm搭建一个支付结算的服务,学完spring后搭建一个购物服务,再通过rpc技术和其他服务整合起来。

  这么做一方面可以通过动手开发的方式来做项目,让我们对已有的技术进行一个查漏补缺,因为在开发这些微服务案例的同时,你就会清晰的认识到这些技术里边哪些是重点,哪些又是自己当初在学习室给遗漏掉的。

  另一方面,这种微服务项目可以保持我们对技术的一个新鲜度,比如说ssh,可能是你半年前已经实现好了,现在和spring联调的过程中,你自然也会对半年前的ssh进行一次复习了,那可以解决刚才的第2个问题就是防止遗漏的问题了。

  到这里相信大家已经掌握了一种持续学习的方法了,这里的持续本身包含迭代和复习巩固在里面。

强化学习也可以理解为整合学习,是一种复习也是一种补漏,交叉螺旋上升,是在深度学习基础上的进一步巩固和强化,也是对知识的的一种水平延展。

技术难点

  最后再给大家讨论一下,如何学习技术难点,我们可以将技术难点分为两类:

  1. 一类是偏理论的
  2. 一个是偏实战的

偏理论

  像数据结构和算法、设计模式以及架构设计等一些技术,都是较为难以理解的偏理论型。这些技术也经常是处于开发者在进阶路上的绊脚石,那我应该如何才能顺利的跨越这些障碍呢?

  我认为可以采用先拆解目标在集中消化的方式来学习,举个例子对于算法设计模式等一些难以理解的技术来说,尽量不要想着花一周或者一个月就把他们彻底搞定了,而应该先计算一下这些知识的数量,然后用碎片化的时间去学习。  

  

  举个例子,假设你想要学习算法,那首先要先计算一下这些算法一共有几个,比如说有30个,那就把这些算法再根据难易程度进行排序,有了这些难易排序之后,我们就可以用碎片化的时间将30个算法逐个进行攻破。

  比如在上下班的地铁之上,在晚餐后的半小时,或者说在睡前的一段时间,利用一些碎片化的时间去学习某一个算法,如果能真正的加以高效利用起来,相信你一定能够在不知不觉里边克服很多难点,从而减少对难点的为难情绪。

  如果难点攻克差不多了,那此时就可以采用一个比较集中的时间,将它彻底消化掉。

偏实践

  接下来我们再聊一聊,如何学习篇实践性的难点技术,这里称之为实践,是因为有些技术必须借助于开发工具来追踪代码或者调试才能掌握的,比如说阅读一个框架的源代码,就是学习偏实践型技术的一个典型代表了。

  对于偏实践性的技术学习,最主要的就是要在实践之前,心里边已经对要实践的内容有了清晰的基础理论了,实践仅仅是一种揭晓谜底的过程。

  这里给大家换一下我当时学mybatis框架时的一些情况吧,当时在我阅读mybatis框架源码之前,我已经对这个框架应用比较熟悉了,因此我清晰的知道mybatis执行的步骤和流程。

  

  现在仅仅是想通过阅读源码,亲眼见证一下它的底层到底是怎么实现的而已,于是我通过开发工具,通过debug进入的源代码……

  当然考虑到每个人对技术的基础掌握是不一样的,每门技术也有很大的不同,所以不同的人在不学习不同的技术可能会存在很多的差异,但我相信这个学习新技术的整体思路是一致的,就可以先通过快速的整体阅读,然后逐步积累逐步深入,可以说这应该是一个比较不错的学习方法吧

学习气氛

线下共同学习

  在很多时候开发者的学习时间都是比较孤独的,都是一个人趴在电脑前,一定程度来讲,个人学习的气氛实际上是没有团体好的,大家可以回想一下是不是在高中的自习室,或在大学的图书馆里的学习系统就比较好呢?

  所以如果你有很多志同道合的朋友,那么完全可以邀请他们来一同学习,所谓独学而无友则孤陋而寡闻。

线上分享学习

  如果不方便,你也可以注册一个微信公众号或者说技术博客,再或者也可以将自己学习的一些项目部署在云端,然后开放给大家一同来访问。

  总之,重点就是要想办法将自己的学习成果分享出来,让大家一起来阅读一起来访问,一起来监督你的学习,并且你也可以通过留言功能与大家进行一个互动。

  如果你是讲师,也可以把自己学到一些知识录成视频分享出去,我相信如果你坚持这么做,除了能够营造自学的气氛以外,还可以将自己学到的基础沉淀下来,慢慢的也会为自己吸引到一批技术爱好者,从而提升自己的影响力,是不是一举多得呢?

总结

今天的分享到这里就结束,最后再总结一下:

  • 在学习新技术时我们可以先快速的了解一下技术的宏观内容,观其大略,找到其中的套路和代码流程或者模板。
  • 然后从hello world开始,逐步搭建一个案例库,通过案例倒逼自己深入学习,从而掌握技术的广度和深度
  • 当案例后搭建完毕以后,再通过微服务技术和其他服务进行一个整合,从而形成一张更大支持网络,不断让自己长期的可以接触到这些技术,防止遗漏
  • 对于一些偏理论性的技术可以用碎片化的学习时间来逐个攻破,减少自己对难点技术的恐惧心理
  • 对于一些偏实践性的基础来说,我们需要在实践之前,心里已经对事件的内容有了一定的了解
  • 最后建议大家也可以将自己学到的技术分享出去,做好记录成长的同时,也能不断的提高自己的知名度。

  以上颜群给的更多的是学习方法,另外左耳朵耗子在《如何超过大多数人》中,从更多维度来探讨学习内容,包括知识来源,学习方法,具体操作三个维度,写的也是让人拍案叫绝。

知识来源

  • 信息渠道
  • 信息质量
  • 信息密度

学习方法

  • 知识树
  • 知识缘由
  • 方法套路
  • 学习金字塔(是一种认知也是一种具体方法)

技能打磨

  • 刻意练习,精益求精
  • 故意犯错
  • 和高手过招

参考资料

原文地址:https://www.cnblogs.com/jackyfei/p/12313526.html

时间: 2024-10-08 12:43:36

《如何快速且深入的学习一门新技术》读后感的相关文章

大道至简第五章读后感

第五章 失败的过程也是过程 今天照样老师带领着我们阅读了大道至简第五章,阅读了<大道至简>的第五章,这章在前面的基础上又进了一步,有了技术和团队,加上有效的沟通,接下来就要接项目做工程. “虚有其表耳”,本章以<明皇实录>中的一句话来告诉我们一个深刻的道理:不要只求外表,只做形象工程,而是要透过表象,力求实质. 失败了不要紧,没有失败也就找不到自己的不足,也就不会发现自己的问题,更不用谈改进了.我们的前辈们就是在不断的失败中才总结出了“瀑布模型”“螺旋模型”等模型,方便了我们.但是

大道至简 第五章读后感

第五章 失败的过程也是过程 以得失而论,在瀑布模型与RUP模型之间,学习前者而不成,可思过程的本质:学习后者而不成,可得文字的架子. 如果懂得了所谓的模型原本都演化自那个简单的瀑布,那么文档是按XP写还是按RUP写,也就可以应时.应需,因地置宜,择善而从了. 越是简单的东西,往往越是接近于本质. 项目经理的工作,就是要去组织这个工程中的各个角色,使得分工明确,步调一致,共同地完成这个项目.四川有句地方话叫“做过场”,也有说成“走过场”的.“过场”是舞台术语,意思是角色从舞台一端出场,再走到另一端

大道至简 第五章 失败的过程也是过程 读后感

今天该写一写大道至简第五章读后感了. 首先是“做过程不是做工程”,过程是为了实现某种目的而经历的一些事情,过程有很多种,虽然经历了某种过程,但不一定能实现某种功能.做完过程的每一个阶段,并不等于做工程.做过程不是做工程的精义,也不是最终目的. 然后是“做过场”,做过场就好像是一种形式一样,做了没必要做的事情,就是浪费时间. 我们为什么做工程,不要忘了最终目的.目的,是实现客户的要求,工程只是一种实现的途径.最初做开发的前辈们,不用什么工程或者过程,也一样编出了程序,也一样解决了问题,也一样实现了

大道至简第七章读后感

大道至简第七章读后感——现实中的软件工程 “王不如远交而近攻,得寸,则王之寸:得尺,亦王之尺也.”——<战国策.秦策> 1:大公司手中的算盘 文中列举了IBM,Borland和Microsoft的一些体系,来说明大公司眼中的世界. 大公司们在标准.理论.语言上的争来夺去,未必全然出于“软件实现”的考虑.对统一理论.统一工具.统一过程的企图,其最终目的是在整个软件工程体系中的全面胜出.算 盘 上 的 绝 大 多 数 人 , 只 是 用 于 计 算 胜 负 的 一 枚 算子.所谓编程语言,只不过是

大道至简第五章阅读感想

第五章失败的过程也是过程 今天王建民老师依旧带领着我们阅读了大道至简第五章,第五章是失败的过程也是过程.通过前面的技术.团队和沟通,这章主要讲了关于做工程的问题. 文章开篇以一句<明皇实录>中的“虚有其表耳”来说明一个很重要的问题就是:不能只求外表,而是要透过表象,力求实质. 第五章的整体思想是让我们注重过程,因为有很多人从来不注重过程,只注重结果.然而过程对于一个编程人员也是非常重要,如果一个好的编程员从来不在乎程序的过程,只是关心最后程序是否能够实现,那么这个编程员一定不是一个好的编程员.

大道至简 第六章 读后感

说点什么呢,今天看了看大道至简第六章<从编程到工程>. 文章以<列子·说符>的“得其精而忘其粗,在其内而忘其外:见其所见,不见其所不见,视其所视,而遗其所不视.”为题记.第一节讲了“语言只是工具”,作者讲述了他曾经对一些编程语言的看法.他曾经也热衷于讨论语言的优劣,但是他现在不这样了,他已经不再专注于语言, 正如他在第一章中写到的一样:成天讨论这门语言好,或者那门语言坏的人,甚至是可悲的.确实,程序的好坏不在于语言,在于算法. 第二节又写了“程序”,程序=算法+结构,编程的精义于此

《大道至简》第一章读后感

经常听见有人抱怨编程太难,说自己不是学软件的料,那么他们真该好好看看<大道至简>这本书,相信他们看完这本书后会有很大收获. <大道至简>第一章引用了一个很简单的故事“愚公移山”,用这个故事很好的概述了我们在完成一个项目时所要进行的步骤.听上去“愚公移山”和编程简直是风马牛不相及,但是看过作者的叙述又有原来如此的感觉.其实编程并没有什么难懂的,就和我们日常生活一样,发现问题,分析问题,提出解决问题的方案,实施,和后续的验收.例如某天我们突然发现家里放不出水了,这就是发现问题,我们会观

大道至简第三章读后感

---恢复内容开始--- 大道至简第三章的是团队的问题.我们知道,随着人们生活水平的不断提高,用户对计算机软件的功能要求也日趋上升.这样一来,计算机软件就变得越来越复杂,规模变得越来越庞大,源代码的量也越来越多.在这种市场需求和自身发展的共同要求之下,一个团结而高效的开发团队的作用就不言而喻了.那么如何打造一支强有力.听指挥.能干活的开发团队呢?这一章作者就这个问题和我们展开了讨论. 作者着重的强调了项目经理在开发团队中的作用.首先声明一点,这并不是说团队的开发人员不重要,作者从始至终都认为编程

一切都是为了实现-大道至简第六章读后感

大道至简第六章的内容比较多,也比较深.或者说这一章作者是从一个更高的层次.更开阔的视野.更独特的角度来解读软件工程这四个字的具体含义的. 作者的这些肺腑之言都是作者在软件行业工作了多年之后总结出来的.开发技术对一个软件产品质量的好坏和最终的成功的影响并虽然不能说是一点也没有,但也不是很大.真正起到决定性因素的不是那些技术细节,而是一个高度过程化.通晓方法论.拥有大量工具的开发团队或者是开发公司.在这个团队里面,无论是对项目经理还是开发经理甚至是一个普通的开发人员的要求都是很高的.团队内的每个人必

《大道至简》第一章读后感和伪代码

阅读了<大道至简>第一章,感到作者对编程的精义分析非常具体形象,引用<愚公移山>的故事,说明了编程的本质.又将他们扮演的管理者,技术人员,程序分析师众多形象展现出来.又在困惑人们的"我能不能学会编程"这一问题做出回答,作者列举生活实例,给出了肯定的答案,将很多抽象的东西,简单化,通过最常见的生活中的实例介绍"大道". import java.大道至简.*; public class.yishan.*; { public static void