实验室集训已经有很多次了,可是并没有什么资料所留,所以我想把我们要讲的东西以博客形式记之,并收录为一个系列。不仅是为讲课之便,更是为后来者留下珍贵的资料以作参考。
本次技术分享为Java后端开发分享,考虑到各方面因素,我不会去讲实际开发中需要的技术要点,我主要分享一下我一路自学过来的所摸索出的经验和初入IT世界的一些感悟、看法。希望我接下来讲的这些对大家有所帮助、有所启发。
你是否问过自己:
你学习Java是为了什么?
工作,兴趣,还是学校安排?
搞清自己的学习目的很有必要,因为它会支撑起你的学习热情和学习方向。
对于我而言,其实很简单,我想做一款app来证明自己,多方搜索决定从Java开始。也许是一时冲动,但我不后悔!
就是这个目的支撑了我一年的学习——每当自己遇到困难,陷入迷茫时,自己亲手组建的团队、当初的豪言壮语和许下的承诺都是支撑我坚持下去的动力所在。我不能放弃,我也不敢放弃,因为我不仅要对自己负责,还要对我的团队负责,更要对我当初的“梦想”负责!
所以我不能退!
这个目标也为我的学习指明方向,后端用到Java,我就去找Java视频看;需要学数据库、服务器,我就去找相应的视频;app协作开发需要用到项目管理工具git,那我就去学git。总之,你要学什么取决于你想做什么。
所以,如果你还没有一个能说服你自己不管不顾去学习的目标,那么我建议你停下来思考一下——你到底想要什么?
自律其实对于一些三心二意的人来说确实很难,但是影响着我们的学习效率。
你在学习的时候,千万不要把手机放在旁边,不然当你光明正大的拿起手机然后对自己安慰:我就看看qq有什么消息,看完就放下。然后你就陷入手机无法自拔,吸引你注意的可能是一个推送又或者是随手点开的视频,等你放下手机时可能已经半小时过去了。
对于自律,我的理解是——你可以玩游戏,可以刷视频,但是你在学习的时候就是学习,不要干其他的,要确保你学习的效率。就算你自律极差,一天只学习一小时,那你也得管住自己确保那一小时的效率。
引用CSDN知名博主一个处女座的程序猿的话来讲就是——
如果你管住了自己,就可以拥有越来越多的自由。自律的本质是什么?是改变。为了美好的期望,主动走出舒适圈,去探索更好的自己。高度自律的人,不会被生活拖曳着前进,而是生活在你的方寸之间,未来变得可控,一切都有条不紊地进行,想要的生活触手可及。
你想要干大事,自信必不可少。
比如你想要参加一个比赛,看到往届比赛选手的优异表现,你可能会觉得他们好厉害,不自觉的就怀疑自己的能力,打了退堂鼓。
殊不知,打败你的不是别人,而正是你自己!为什么别人能做到,你就做不到呢?你连试都没试过,怎么知道自己不如别人呢?
要有自信,相信自己,自己打退堂鼓是因为自己目前的技术能力不够。
那不够就去学呗,你为什么不能成为站在台上的那个人呢?
但是自信不代表你要自傲,对待别人,一定要谦虚,这是一种态度。在这个行业里,大佬比比皆是,你不知道前一秒跟你谈笑风生,问你问题的人,后一秒可能就是帮助你解决问题的人。
折腾对于我们这个行业的人来说是家常便饭了,尤其是你刚接触一个技术时,折腾是免不了的。
当你遇到bug异常时要耐心,这其实也是对你能力的一种考验,真正的大佬正是在这种折腾中越来越强的。
你一定要对自己的学习路线有所规划,要有自己的学习节奏。
当你学完一种技术,不要懈怠,不要觉得自己已经大功告成了,事实上,你只是进入一个更大的世界而已。
你每次学完一种技术,是不是有一种虚浮的感觉?
这很正常,每一种技术,不去实践永远不要说自己掌握了,你要把你的所学记录下来。
写博客就是一种很好的方式。当你向其他人分享自己的所学时,实际上也是在巩固自身。而从功利的角度出发,博客其实也是你实力的证明,一些面试官很喜欢看你的博客,因为他们可以从中看到你做了哪些事。
当然有实力也可以参加一些开源项目,这对于自己的成长将会有很大的帮助。
大家学习的时候可能都会遇到这么一种情况,学着学着发现有个地方听不懂,搞不明白了。
怎么办?
我的建议是回放再听一遍,如果还是听不懂,那么果断跳过去,不要去纠结。
学习,尤其是前期学习,要以构建知识体系为主。很多东西你目前可能不懂,那是因为你的知识体系不够完善,等你学完后面的,说不定前面不会的就很顺利的解决。
切记不要钻牛角尖!
比如,你在学习些helloword时,你就不要纠结System.out.println() 为什么能够输出。因为这涉及到后面的输入输出流,以及面向对象的思想,你说你入门去纠结这个有什么意义呢?
所以构建知识体系才是你的当务之急!
首先,先明确一个问题——自学编程最有效率的方式是什么?
我会毫不犹豫地回答——做项目!
不会做项目呢?
看教学视频,其次才是看书。
以下是技术up主CodeSheep和培训班推荐的学习路线
说说我的学习路线吧。
首先大一学c的时候,我就课外自学c语言,看的是b站的鱼c小甲鱼的视频。结果就是要上一学期的c语言被我14天学完了。
剩下的时间我学的是Java全栈学习,其实我当时看的那个只有三百多集,这个一千多集是我学完之后发现的。
跟着这系列我学到了很多,再加上我平常逛b站和知乎,自己对于Java学习有了新的理解。
到了框架部分,我就开始跳脱开这个视频系列,不是说它不好,只是它有些过时了,学学基础部分还好,毕竟基础不怎么变,但是到框架部分就开始有点乏力了。
至此,我已经学了Java基础、tomcat服务器、网络编程、mysql、oracle数据库。
我开始根据自身的需求来找合适的视频,后来学了
maven、git、mybatis
之后恰逢短学期程序设计,我根据我的所学写出了第一个我独立完成的项目——【项目实战】 图书信息管理系统(Maven,mybatis)(第一个自己独立完成的项目),这个博客出乎了我的意料,截止到我写这篇博文时,浏览量已经破4万了,收藏破2000,这给了我极大的鼓舞。
其实这之间我也忙了些我那个项目的事情,不过与主题无关,我就不细讲了。
再之后我学了Spring、SpringMVC、SpringBoot,期间我参加了校软件创新实验室的集训,不过我是讲课的那个。
为了巩固自身所学,我完成了我第二个项目——【项目实战】个人博客(SpringBoot,SSM,thymeleaf,Semantic UI)——从设计思路到成品
后来我选择继续往上学习分布式微服务架构,同时也写下了分布式微服务学习总结系列文章。
随后我意识到分布式微服务在学生时代很难去实践,很难应用,因为我们没有足够的资金和适合的场景。于是我放弃继续研究学习分布式微服务架构,转向巩固基础知识,深入底层,因为那时候的我基础差的一塌糊涂,很多东西只知其然,不知其所以然。
而那时的我对于技术并没有那么多思考,框架也只是到勉强会用的程度,那时的我往往会有种焦虑。因为我常常会想技术这么多,而一旦主流技术变更,那我将何以立足?
一种深深的焦虑蔓延开来。
随着我不断巩固基础、学习较为底层的知识(如阅读经典著作)以及写相应技术博客,我的知识体系漏洞在不断修补。不仅如此,我还在在学习一些大佬的课程,里面的一些思考和观点往往能给我一些启发,渐渐地,我拨开技术的迷雾,渐渐理清了一些技术脉络,而那种焦虑感也在这种学习中消失了。
比如,阅读Java的经典书籍Thing in Java(Java编程思想),学习大佬的课程(如软件设计之美、左耳听风、从0开始学大数据、深入理解Java虚拟机),这些不仅能让你在学习到具体知识点,同时也能锻炼洞察问题的能力,学习一些好的思考方式等等。
以上便是我的自学历程,说实话,在没人领路的情况下,走弯路是在所难免的,不过这种走弯路所带来的成长也同样弥足珍贵。
在校大学生在空余时间自学点东西是非常重要的。
但也别忘了学校的课程,虽然有时候有些东西会显得落后,但是有些课程还是不能拉的,比如数据结构、计算机网络、操作系统,这几门课会实实在在影响到你未来的开发。
然后,自学的路线我推荐按照B站狂神说的路线来,我稍微看了下,讲的还是比较有意思的而且路线选择考虑的也挺全。专栏地址
当然学完一项技术最好自己去敲代码实践,尤其是学完SSM、SpringBoot时,可以尝试去开发自己的项目,这里我推荐自己尝试去做个个人博客网站,因为这既能锻炼你的能力,开发出来的项目自己也能用,一举两得,何乐而不为呢?
在讲这之前,我相信大家对于开发来说都没什么概念,所以我觉得有必要先说一下传统开发的架构示意图:
Springboot vue前后端分离架构
前后端分离 系统架构图
实际上,真正大厂的项目系统架构远比上面复杂,这也是为什么他们能够抗住如此多的用户流量冲击。
这也是上面我说学生时代根本玩不起分布式微服务架构的原因所在。一个太复杂,需要大量成本(资金、人力);一个是缺少合适的场景(自己开发的项目根本没必要这么去弄,因为也不会有多少用户)。
了解完传统开发的架构后,再来了解一下我们平时web开发和App后端开发。
其实啊,这两者都是一样的,因为区别实际上就在于前后端分不分离的问题。
对于web开发,你可以把浏览器看出客户端,而这个客户端比较特殊,因为它可以当做很多网站App的客户端,所以它要求把页面的数据传过来,这时候传统的做法就是后端把经过数据渲染的页面代码传到浏览器,这样呢,我们也就看到了一个个页面。(但在这里我们看到,前端和后端代码实际上出现在同一个项目中,后端需要承担页面数据渲染的工作,这样对于后端接口设计产生一定的影响,加大了后端的负担,不利于后期维护和前后端沟通协作)
如下图,
我可以看到后端代码中掺杂了各种前端代码。
还有一种做法就是前后端分离,前端后端有自己的服务器,这时候,前后端代码部署就只需各布置各的,而后端呢,就只需做好前后端交互的接口和数据处理的工作即可,而不必关心页面数据渲染的问题。
而App开发其实就是一种典型的前后端分离项目,后端所做的只需提供相应的接口,待请求到达时返回所需的数据即可。
当然,说的很轻松,实际上,数据处理要考虑的东西可多了,很多时候你不仅要考虑业务的实现,还要考虑系统的性能等等因素。
学一项技术,我觉得最起码得了解它的来龙去脉,清楚它是在什么背景下诞生的,明白它是为了解决什么问题而出现的,了解它解决问题的原理和设计模型,再稍微想想如果设计者是你,你会如何去做…
这么思考下去,相信我,你会有质变的。(当然这点我也是最近逐渐领悟get到的,我实际上也没有达到这一点,但我在向这个方向看齐)
仔细思考计算机的发家史,不难发现,计算机、互联网之所以能改变我们的生活,改变世界,原因就在于它把世界“抽象”出来,在另一个维度描述生活,描述世界。从纸币支付到移动支付,从人力生产到智能智造,从现实生活到虚拟现实,这一切不就是互联网时代下的真实写照吗?
无论是区块链,还是物联网,亦或者是深度学习,这些技术的核心都是相同的,那就是——数据!
区块链提出了数据的分布存储来实现数据的去中心化;物联网拓展了数据的来源,构建了一个万物互联的美好世界;大数据更不用说了,本就是围绕大量数据展开的一项技术;人工智能,通过算法使计算机对大量数据进行分析学习,以达到某些不可思议的效果;后端开发更是对数据进行处理存储,包括现今流行的分布式微服务架构,其实就是为了提高处理数据的效率;前端开发是对于数据的可视化展示…
你看现今这些技术本质都是数据,都是围绕数据来展开的。
我们应该认识到这个世界上除了我们眼睛看的到的世界外,还有眼睛看不到的数字世界。
那个充满数据的世界,那由无数个0和1构成的数字世界!
互联网时代下的各种技术,本就同根同源。
面对某项技术,或者某个问题,我们不能割裂的去看待,我们应该有种思维——融合自己的所学去学习技术,去解决问题,而不被某项技术给“绑架”。一旦你有这种思维,那么对于某项技术,你可能会有自己的思考;对于某个问题,你也许会有新的解决方案。
kafka是是一种高吞吐量的分布式发布订阅消息系统,每当我们提到kafka,首先让我们想起的是它那极高的性能,为什么它能有如此高的性能?原因就在于kafka的设计者并没有和其他设计者那样局限于某项技术,某种思维,他将创造式地将软件硬件结合起来,最终实现了其他人所达不到的性能。
区块链技术其实和后端架构思想中的分布式非常类似,个人看来区块链技术,包括大数据分布式处理,都是从后端分布式思想演化过去的。区块链的去中心化思想和分布式思想真的极其相似,有着异曲同工之妙。
如果我们往深了想,其实分布式思想也是由其他思想演化而来的,它和计算机处理数据的思想之一——牺牲部分效率换取更高的效率——有着异曲同工之妙。计算机虽然没有人类智能,不能通过某些取巧的方法去处理问题来提高效率,但是计算机胜在执行速度快,就算是有重复冗余的操作,也比我们人类运算快的多。
而分布式也是如此,各台计算机之间通讯、协调会耗费许多资源,但是如果这个计算机有很多很多台呢,那就算耗费这些资源,大量计算机“合作”往往能完成许多我们看似不可能的事情。这也是分布式思想的魅力所在。
再往深了想,或许这跟我们人类社会的分工合作有些类似,众人之间协作或许会耗费精力,还要处理各种人际关系,单个看效率确实没有单干高,但是团队协作所能做到的事情往往是单干无法企及的。
总之,千万不要去割裂看待某项技术,当今前沿技术中,无论是大数据的数据挖掘与分析、人工智能的深度学习、区块链的去中心化,还是物联网的群智感知,亦或者是服务端的分布式微服务架构,这些都是互有联系,相互促进的整体。
比如,大数据为人工智能提供数据基础,物联网为大数据提供获取数据的方式等等…
我们应该对其有着客观的认识,不要割裂地去看待技术和问题。
这个观点来自于极客时间的从0开始学大数据,当初看到这个时,感觉特别好,特此分享出来
Hadoop MapReduce 虽然已经可以满足大数据的应用场景,但是其执行速度和编程复杂度并不让人们满意。于是 UC Berkeley 的 AMP Lab 推出的 Spark 应运而生,Spark 拥有更快的执行速度和更友好的编程接口,在推出后短短两年就迅速抢占MapReduce的市场份额,成为主流的大数据计算框架。
读到这里请你先停一下,请给这段看似“没毛病”的引子找找问题。
不知道你意识到没有,我在这段开头说的,“Hadoop MapReduce 虽然已经可以满足大数据的应用场景,但是其执行速度和编程复杂度并不让人们满意”,这句话其实是错误的。这样说好像可以让你更加清晰地看到事物发展的因果关系,同时也可以暗示别人自己有洞察事物发展规律的能力。然而,这种靠事后分析的因果规律常常是错误的,往往把结果当作了原因。
事实上,在 Spark 出现之前,我们并没有对 MapReduce 的执行速度不满,我们觉得大数据嘛、分布式计算嘛,这样的速度也还可以啦。至于编程复杂度也是一样,一方面 Hive、Mahout 这些工具将常用的 MapReduce 编程封装起来了;另一方面,MapReduce 已经将分布式编程极大地简化了,当时人们并没有太多不满。
真实的情况是,人们在 Spark 出现之后,才开始对 MapReduce 不满。原来大数据计算速度可以快这么多,编程也可以更简单。而且 Spark 支持 Yarn 和 HDFS,公司迁移到 Spark 上的成本很小,于是很快,越来越多的公司用 Spark 代替 MapReduce。也就是说,因为有了 Spark,才对 MapReduce 不满;而不是对 MapReduce 不满,所以诞生了 Spark。真实的因果关系是相反的。
所以顶尖的产品大师(问题解决专家),并不会拿着个小本本四处去做需求调研,问人们想要什么。而是在旁边默默观察人们是如何使用产品(解决问题)的,然后思考更好的产品体验(解决问题的办法)是什么。最后当他拿出新的产品设计(解决方案)的时候,人们就会视他为知己:你最懂我的需求(我最懂你的设计)。
以上我分享了我觉得自学中需要注意的几个点和后端开发的学习路线,也讲了传统开发架构模式,同时也分享了我学习过程中的一些感悟和我看到比较新比较有深度的观点。希望我以上讲的这些会对你有点帮助。
软件创新实验室Java后端开发小组
写于2021年1月28日