掌握概念的含义

  • 作者:KK

  • 发表日期:2016.9.21


编程知识中会有很多概念,新手学习阶段通常是记不住全部的,但随着经验慢慢增加,应用得越来越多,然后就会在心中积累越来越多的编程概念了

比如说面向对象编程中有一个概念叫方法,对象都有方法,但它不是函数,我看到很多普通程序员都将方法称为函数,但书籍、一些框架什么的官方教程里从来不这么说

如果不注意记住一些概念的含义的些,一旦遇到术语比较正规的文章、教程的时候就会懵B,或者似懂非懂地学了过去(我看到好多程序员都是忽略了这个概念名词,然后跟着教程鼓捣下去却没出现和教程一样的效果)

还有就是一些理论级别的文章会学不懂,导致很快就迎来了个人能力的瓶颈,其实我想大部分普通程序员反思一下自己进步为什么被卡,是不是都依赖搜索引擎找来的那些

我个人的进步暂时还没遇到瓶颈,因为一切要学的东西我都能看懂并且应用起来,使之产生更大价值,所以我是能够一直进步下去的

其中最大的帮助就是阅读了各方面技术的官方文档,这些官方文档中含有很标准的术语,但我都能理解里面的含义并正确运用


有没有发现其实身边的程序员其实并非笨蛋,只是你与他之间沟通上可能有误差导致了他往左转,你在向右转,最终走不到一条路上

而当越走越远时,你大声喊他一下说他走错方向了,然后你就要开始跟他讲他为什么走错了,最后他就理解了……可是当初他为什么会理解错误呢,是你的术语没能让他明白对不对?

然而如果你把你的问题放到网上一问,通常又能得到很多正确的理解和回复

其实当大部分人都能理解一个概念术语时,那你的表达就能与他人产生很良好的沟通效果

也就像我现在理解常用的概念后,阅读各种“枯燥的”文献时却能快速顺利地消化,因为他们用专业的概念术语讲话时,我也用专业的概念去理解它


打个比方,讨论ORM的取舍问题

  • 我会直接拿“ORM”这个概念去讨论

    我问过一位前辈:“ORM模型的效率有点低下,但不用ORM又导致架构不够灵活,你又是如何取舍的呢?”

    前面回答:“前台需求多变,用ORM就可以灵活调整,性能敏感的再用DAO;而后台需求不多变,可以不用ORM来换取性能”


  • 与不懂概念的人对比:他们用一通话去描述ORM再问取舍的问题

    我见过一些普通程序员经常是这样问问题的:“查询数据库结果后将它赋值到一个对应的模型对象的属性里,然后通过操作这个对象的属性来操作数据,在这个模型里封装一些业务方法针对这些数据处理虽然很方便并且程序结构很清晰,可是联表查询时又不是很方便,如果只要查一部分属性的话这个对象的属性就不完全了,这种设计用起来好像不是很完美,并且会有比较多的查询,我不如不用这种模型直接查数据操作好呢?性能又高嘛!可是这样又好像导致程序结构不是很清晰,久而久之就代码有点乱,怎么办?”

其实他讲了这么多就是在讲ORM这个东西的好坏,然而实际上他就是不懂什么叫ORM,又然而实际上他可能用了TP框架或其他框架好几年了,官方文档都一直说ORM ORM,然后他还是没懂啥叫ORM……也不去搞懂……

所以这里也说明了为什么我见过有些人在他的文章里分享他的面试经验时会提到“有时候你就会发觉和高手交流就是这么流畅”,其实因为他们都共同理解一个概念,不需要多解释,简单描述一下就好,然后直奔问题的探讨环节


清点一下我常见的概念或技术名词

  • 标准

  • 标准输入

  • 标准输出

  • 标准错误输出

  • RFC

  • 协议

  • 无状态

  • REST

  • SOAP

  • RPC

  • RBAC

  • 参数化

  • 结构化、非结构化

  • 粒度

  • 透明

  • 抽象

  • HTTP、SMTP、TCP、IP、UDP

  • Host/主机

  • 域名、二级域名

  • 签名、签名证书

  • 单向加密、双向加密

  • 可逆、不可逆

  • 认证

  • 授权

  • 模型

  • 业务

  • Map、映射、集合、阵列

  • Context/上下文

  • push/推、pull/拉

  • hook

  • callback/回调

  • 终端

  • Client/客户端、Server/服务端

  • 交互

  • 会话

  • 缓存

  • build/构建

  • 语义化

  • 迭代

  • 沙箱

  • Dump

还有更多就不说了,能快速想起的主要的就这些吧,如果掌握这些概念,其实阅读很多资料,与人交流都是很快速方便的,进步就快了