你所听到的技术原理、技术本质到底是什么?
职场的程序员们或多或少都受到过前辈或领导的指点,应该都听过这么一句话 “学技术不能光会搭建个环境,使几个API,要学习了解技术的本质”。可能实际听得比较多的是 “学习技术原理”这句。所以这两个点都会说到,会说一说区别及联系。
原理,何为原理,技术原理到底在学什么?
本质,何为本质,怎么就算了解掌握技术本质了?
本文就来码一码技术原理和技术本质这两个东西。
一、技术原理
先说一下「技术原理」这个词,这个应该大家都很熟悉,每每提起甚至感到一丝丝痛苦和折磨,一线互联网公司面试官的最爱,经常拿来挑逗一下面试者,"知道xx技术的实现原理吗?能不能说一说"。
技术原理即技术背后的 实现思想、架构设计、代码 ,学习一个技术的实现原理就是学习这三个方面的内容。
这三个方面也是层层递进的关系,越来越具体。
首先,思想是宏观的东西,构建起整个技术的理论支撑;
其次,架构是思想的进一步推敲和论证的产物;
最后,就是代码了,结合思想和架构设计变成一行行的可执行代码。
所以,你看学习技术原理的路线图和目标就出来了,第一,学习思想构建起宏观概念 ;第二,学习整体架构及局部架构掌握整体结构的组成和相互之间的关系;第三,学习代码的实现和逻辑。
举例说明一下,学习 "HashMap原理",这时候首先应该构建起的是它的数据结构知识即哈希表的概念和特点(其实如果再拔高一点,应当是先建立起各种数据结构和相互之间区别、特点及相关算法的思想和理论知识,当然这个要求就稍微高一些了),然后架构设计因为这是一个具体的类,所以这部分就是类中包含的核心方法及作用,最后就是深入代码,学习具体的代码实现逻辑,比如put方法是怎么存入数据的,又在什么情况下会进行扩容等等。
如果没有前面部分的思想和理论做支撑, 不建议直接上来就进入到代码细节,会学的很痛苦比较挣扎。发现概念和理论上的盲区,应及时补上,然后在继续代码的学习。
二、技术本质
说完技术原理,下面看技术本质。简单理解,技术的本质就是解决问题,将解决问题的前因后果分别具体化研究,展开来说本质就是除过上面说到的技术原理之外,还应该包括 技术所解决的核心问题 和 应用场景 以及 存在什么样的优势和不足。
总结一下,就是以下3点内容:
1、技术解决的核心问题和应用场景
2、技术原理
3、技术特性
所以,你看学习技术本质的路线图和目标也就出来了,第一,掌握技术解决的核心问题和应用场景,即搞明白它可以用来干什么;第二,研究技术原理,即搞明白它为什么可以做到;第三,了解它的技术特性,即搞明白它的优势在哪里。
拿redis来说,它解决的核心问题是提供高性能的内存数据缓存服务。虽说官方认为它还可以用作数据库和消息代理,但实际应用中更多作为数据的缓存服务。
技术原理上面专门做了介绍了,读者可以类比理解,这里就不在展开了。
技术特性即是该项技术与相关其他类似技术相比有什么牛逼的地方,拿redis和memcached比,多数据类型的支持就算redis的一个特性,持久化能力的支持也算是一个特性。特性在做技术选型的时候往往有着至关重要的作用。
搞清楚一门技术以上3点内容,才算得掌握到技术的本质。我们再学习技术原理的时候,不妨再加把劲,窥一窥它的技术本质。
再带大家理解一下「本质」这个词,下面这句是摘自网上的一句话
IPFS本质上是一种内容可寻址、版本化、点对点超媒体的分布式存储、传输协议。
从面上看更像是一句定义,告诉你什么是IPFS,但是加上了本质二字,就让这句话看起来不是那么的简单,而支撑本质二字的背后就是IPFS这个技术的是内容可寻址,具有可以版本化、点对点、分布式传输的特性,解决的核心问题和应用场景就是标准化数据传输过程。
所以作者一定是窥透了这技术背后的本质内容而总结出这么一句话。希望这里没有让你看糊涂。
当我们再看到“xx的本质是xx”这种类似的话的时候,希望大家能多思考思考这句话中本质背后的支撑是什么,有点跑题了,收回来。
三、总结
可以看到,技术本质包含了技术原理,也就是一种包含关系。
本文就是理清技术原理、技术本质的真正含义和关系,经常我们对这些看似都懂的概念不去深究,而实际上真正搞明白这些东西能够帮助我们搭建自己的知识体系,而且知识结构脉络十分清晰,不易混淆。在学习一门新技术或深入研究一门技术的时候也会有一个清晰的方向和目标。
最后,随着学的东西越来越多,越往后大家就越会发现概念和理论(也就是思想)的重要性,有清晰的概念和理论体系作为支撑,能让我们的学习事半功倍。
关注作者公号「风象南讲全栈」,做有思想的技术人。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
马蜂窝消息总线——面向业务的消息服务设计
引言 马蜂窝消息总线于 2017 年 11 月份上线,截至目前,已经被电商、酒店、大交通、社区等多个技术团队投入到生产环境的使用中。 近一年时间里,消息总线经历过几次比较重要的功能迭代,承担了 PHP 在线服务异步、削峰、解耦的大部分任务。 这篇文章的目的主要是和大家交流下马蜂窝消息总线的设计原因、实现原理以及未来规划,希望能和有潜在需求的研发同学一起探讨。 我们为什么需要消息总线? 在消息总线上线前,马蜂窝大部分业务中的异步需求是通过 Redis 队列来实现。随着消息量增加,经常会出现消息积压、不同消息之间互相影响的问题。为解决这些问题,电商研发团队开始规划和设计消息总线。 为什么会有消息总线,而不是让业务系统直接用 PHP 或者其他语言对接 RabbitMQ,Kafka 这样的消息系统? 「消息总线和直接使用消息系列有什么实际的区别?」,这是很多研发同学一开始不太理解的地方。假如只是为了用一个性能更好的消息系统代替 Redis,确实并不需要消息总线的这个角色。 但当我们从实际业务角度出发,对公司整体技术架构和开发场景的梳理时,发现如果直接让业务系统对接消息系统,并不是一个很好的方...
- 下一篇
从0到1,了解NLP中的文本相似度
本文由云+社区发表 作者:netkiddy 导语 AI在2018年应该是互联网界最火的名词,没有之一。时间来到了9102年,也是项目相关,涉及到了一些AI写作相关的功能,为客户生成一些素材文章。但是,AI并不一定最懂你,客户对于AI写出来的文章,多少是会做些修改的。为了更好的衡量出AI文章的可用度,在这儿就会需要存有一个反馈的环节,来看看用户润色后的文章与原始AI文章之间的区别是多大,AI写出来的文章可用性是否足够。由于目前还没精力细究AI写作其中的细节,为了更好地计算每次成文与原文的区分,便花了点小时间看了看文本相似度的知识点,记录于此。 本文将从预备知识的概念开始介绍,从距离名词,到文本分词,相似度算法,并将这些概念融合、统一的介绍NLP中文本相似度的知识,期望通过本文,大家可以与我一样,对这些知识有个基本的了解。 几个距离 在介绍更多的内容之前,我们需要了解文本距离的概念,这些距离是我们在后文比较文本相似度的基础,所以下面将首先形象的为大家介绍几个重要且基础的距离含义。 欧几里德距离 Euclidean Distance,是最直白的、最容易直观理解的距离度量方法,在二维空间来看,...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS7设置SWAP分区,小内存服务器的救世主
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- 2048小游戏-低调大师作品
- CentOS8编译安装MySQL8.0.19
- Hadoop3单机部署,实现最简伪集群
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- Windows10,CentOS7,CentOS8安装Nodejs环境
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题