面试官让我意识到[基础不牢]的绝望!
公众号后台回复“学习”,获取作者独家秘制精品资料
经常有同学跟我说,很多的基础知识学过就忘, 比如操作系统、数据库、网络协议等方面的底层原理。而这些往往都是技术面试必考的内容。
每次被问到这个,我都不知怎么回答,跟他说多看几次,就记起来了? --- 这似乎是一句废话,但好像又对,细细想来,这后面还是有不少思考的。
我觉得很多同学在基础知识上的问题,不是技巧的问题,而是对基础知识的态度和理解的问题。
所以,这不是一篇教你怎么学基础知识的文章,而是告诉你基础知识的价值和基础知识在程序员脑海中的演进过程。
对于操作系统,数据库,网络等基础知识的学习,看书,做笔记是必要的。不过我在这里不教大家怎么看书,怎么做笔记,我估计读过大学的同学,这应该不是大问题。
很多人纠结的问题在于基础知识老是看了又忘,然后发现工作上好像也用不到,就开始质疑基础知识的价值,质疑到底该不该花时间去学。
所以先要认可基础知识的价值,意识到了基础知识的价值后,你才会愿意花时间去学习。
基础知识的价值
基础知识的价值,我觉得有两个部分。
一个是技巧层面的价值。
拿操作系统里面的线程和进程来说,线程和进程是cpu调度的基本单位,是代码的一种动态呈现,只要你写代码,就一定会涉及到线程或者进程。
当然在实际使用中可能被框架包装了起来,给人的感知很弱,但一旦你的程序有问题,你总是要用些工具来查看的:查看是那个进程出了问题,要从内存占用,cpu 占用,磁盘读写等来初步分析问题。
以上这个过程,是稍微有点技术含量的工程工作都会涉及的。上面例举的例子,你可以扩展到 操作系统锁,数据库表,数据库索引,数据库锁,数据库事务,TCP/IP , HTTP,websocket 等等。
就工程方向来说,几乎每个方向都要掌握相应的基础知识,只是每个具体方向对每种具体基础知识掌握的深入程度不一样。
像做分布式存储的同学,对数据库表,数据库锁,数据库事务这些的理解肯定是要很深入的;前端的同学对数据库相关概念的理解可以要求低些,但对网络,TCP/IP, HTTP , HTTPS 这些的要求就要高很多。
一个是思维层面的价值。
除了技巧层面的价值,还有思维层面的价值。
怎么来理解这个事情呢?软件设计,有很多核心的设计思想,其实是相同的,这些基础概念,其实也是前人设计和总结出来的。
比如说线程和进程,这些概念不是自然原理,而是一种工程实践后的软件抽象,是前人抽象出来的一个结果。它的设计背后,蕴含很多优秀的设计思想和设计原则。
一开始的时候,你只知道这个概念,可能理解起来都觉得很困难,只能死记硬背,但就像我们小时候学习古诗词,它会给你带来潜移默化的影响。
你脑子里一直装着这些概念,实际工作和学习的时候,遇到相关的问题,你可能就会有点小思考,日积月累,你对它的理解会越来越深。这种理解,我觉得就在不断塑造着你的技术思维。
基础知识的演进
说完了价值,我来分享下,基础知识在程序员脑海中的演进过程。
我觉得对于操作系统和数据库,光看书几乎是学不好的,因为能做的就是背概念,但背完很快就忘记了。
我上操作系统课程之前,看过 linux 的源代码。对于操作系统,因为我花了很多时间在 linux 内核上,所以上操作系统课的时候,很多概念对我来说反而是一个汇总,把我很多离散的知识给汇总起来了。
所以我看进程,线程这些概念的时候,不是抽象的而且具象的,脑子里甚至可以具体到代码层面。
但很多人没有我这么一个经历,所以看起来一脸懵逼也正常。就像我在大学看数据库的时候,我也觉得很抽象,看了就忘,直到我后面自己去做存储,对很多的概念才慢慢地理解深入,开始有感觉。
但这里不是说就不去看了,不看,你就一直都不会知道,甚至连基本的思考都没有。
对于基础知识的学习,其实是循环往复的过程,不是一次性就能掌握的。对于这类知识的掌握会经历这么一个过程:
概念 -> 理解 -> 实践中的思考 -> 概念 -> 理解 -> 实践中的思考 ...
这是一个循环往复的过程,但不是重复,而是螺旋式地深入,每一次循环都能够带来更深入的理解。
我们说一个人技术很牛,有很大部分是因为他对很多的知识点经过了很多次这种循环,他对基础知识理解的深度要高过很多人。
软件技术有两个关键,一个是抽象,一个是分层。
其实你会发现很多的概念,知识点,都是一个具体软件实现的抽象,里面也有分层。
举个例子,我们说进程,你看书上就给了一个概念,你觉得很抽象,觉得这是操作系统里面的一个概念,有点像是原理性的东西。
但你往下一个层次看,到操作系统设计这个层面来看,进程是一个很具象的东西,有具体的代码,具体的设计,具体的细节,甚至有时候你会觉得有些代码写得也不咋地,就像是一个业务逻辑。
从这个层面,这个角度来理解,来看待进程的时候,怎么可能会懵逼,简直具象到不行了,甚至还会觉得这不就是一个业务逻辑嘛。
但深度是不是到这里就停止了,也不是。
你会开始去思考,为什么要有这个设计,为什么要有这种抽象,你可能会去找相关的论文来看。计算机技术不是自然科学,进程也不是定理性的东西,不是 1+1 等于 2 这种自然存在的,所有一切都是设计出来的。
有设计就会有讨论的过程,这些讨论的过程或结果很多都还保留在互联网上。
比如,有一次我们想为自己做的分布式存储,设计事物系统,后来就顺藤摸瓜地找到了数据库大师 Jim Gray 关于事务设计的经典文献和资料,里面有他的很多思考和权衡。
到这个时候,事务在你脑海里已经不是概念,而且一个庞大的东西,很多细节,设计的权衡,你想忘都忘不了了。
甚至你还会思考这种设计是不是最好的,时间过了这么久,会不会不适应现有的场景了,反正你会思考很多。
我们说有人很牛,我觉得这个就是很关键的区别了。
这个过程很艰难,也很缓慢的,要十年甚至二十年的时间,有人可以不断地深入;也有人只停留在很浅的层面。如果你能不断深入,你就能不断地超越很多人,朝着技术大牛的目标迈进。
结语
基础知识的学习和理解是缓慢且不断深入的过程,甚至是贯穿整个程序生涯的,不断深入理解的过程,也是不断塑造自身技术思维的过程。
当然,首先你得知道并认可基础知识的价值,你才会愿意花费时间和精力去不断去学习和深入理解它们。
这篇文章给大家分享了,基础知识的价值和基础知识在程序员脑海中的演进过程,这个视角可能比较独特,不过却也是我这么多年来的心得和感悟,希望对大家有所帮助!
END
下一篇: 数据分析师如何点技能点?
推荐阅读
-
像首席技术官一样思考:如何高效管理 30 人的研发团队?-管理越多越轻松。好的研发团队,应该是上拨下用,即下级对上级的向上管理;而不是反过来,总是向下管理,甚至是 CTO 做经理的事,经理做工程师的事,工程师最终会被当成实习生。如果是这样,就会越管越累,不仅团队无法成长,而且团队整天很忙还效率低下,问题一大堆。 有这样一个小故事:一位高级经理下班后帮忙倒垃圾,结果被老板训斥了一顿。这就好比首席技术官做了实习生自己该做的事。事情本身没有对错之分,只是从不同的角度有不同的理解。 古人云:"用人不疑,疑人不用"。在面对自己的研发团队时,应该相信他们能做好,授权一线开发人员充分发挥专业特长,不要限制他们的工作。但在相信他们的同时,也要进行二次确认,始终秉持 "我相信,但我要确认 "的原则和严谨的精神。因为每个人都会犯错和疏忽,通过发挥团队的智慧,团队犯错的机会就会大大减少。比如回归测试、代码审查、开发演示、变更审批等等。 如前所述,每个人都难免会犯错。但作为管理者,你所设计和商定的流程不能出错。管理者的每一个决定和沟通都应该经过深思熟虑。就像红绿灯的交通设计,某辆车不小心闯红灯可能会扣分,但红绿灯的设计一定要正确、人性化、统一。再比如,开发人员可能会因为疏忽大意写出 bug,但研发流程的设计和上线流程的发布不能有任何差错。因此,流程体系的设计,一方面要结合当前团队规模、业务特点和需要重点解决的问题来设计,另一方面也要在人员防错、效率提升、发挥团队集体智慧等维度进行综合考量。应该站在更高更抽象的角度去思考,不断思考一个倍受欢迎的园区应该如何设计,思考一个灵动、经典、永恒的建筑应该遵循怎样的模式,思考一个成功、优秀、卓越的研发团队应该需要怎样的流程和制度。 最后,反馈很重要。向上汇报很重要,向下反馈也很重要。能够保持顺畅的双向反馈和闭环管理,对研发团队的协作和沟通有着非常明显的积极作用。在向上汇报方面,要培养团队在正式汇报、会议汇报、私下沟通、书面总结、非正式场合等方面的沟通能力,提醒下属报喜也要报忧。凡事先记录,再跟进,最后反馈。反馈很重要,主动汇报更难得。 另一方面,同时也不要忽视向下反馈。好的爱,是双向的。团队也是如此,没有严格的上下级之分,只是分工和角色不同而已。作为管理者,不必总保持一种 "神秘感",让人 "捉摸不透 "才是牛。当团队做得好或有人做得好时,要记得在公开或私下场合给予肯定和赞许。业务有增长、业绩有提升时,别忘了给团队一些鼓励,或者安排一次下午茶或聚餐。在例会或正式会议上,也可以同步向大家传达一些重要信息和高层指示。"欲速则不达,欲远则同行"。 当向上汇报、向下反馈的沟通闭环形成后,同时结合前面研发过程的管理闭环,双管齐下,就能形成良性循环。如此反复,持之以恒,优秀卓越的研发团队,必将呈现。 能力、产出和效率 接下来,继续重复关于能力、产出和效率的话题。 站在不同的角色,以及一个企业经营、生存和发展所需要的基础上,我把研发生产力分为三个层次,分别是:一线员工关心的研发能力、管理层关心的软件产出和操作人员关心的企业生产效率。简单概括就是:既要把工作做好,又要能出成果,还要能帮企业赚钱。
-
面试官让我意识到[基础不牢]的绝望!
-
面试官让我意识到[基础不牢]的绝望!