为什么我学一门语言就已耗尽所有，而有些人还能同时学习多门语言？

大家好，我卡颂。

对于这个标题，相信很多朋友都会有共鸣。不止是语言，每年都会出现新概念、新框架、新特性，让人不禁感慨：「别出了......学不懂了」

但为什么总有一些人，能有精力涉猎多个领域呢？下面是一位老程序员的回答，相信看完会有答案。

授权转载自invalid s的知乎回答[1]，在原文基础上增加了一些图片，提升阅读体验

直奔主题

「因为你学错了」

我最初是学QBasic入的门，自己琢磨着写游戏、搞动画玩。但basic是解释型语言，性能太差，当时奔腾上市没几年，学校机房还是286、386，486都少见。

为了写真正的游戏、为了充分发挥硬件能力，这才中途切换到C；之后面向对象兴起，又自学了C++。

其实多学一门语言很简单：所有编程语言都不过是一套风格略有差异的、执行序列及数理逻辑的描述系统而已。

就好像你学数学，既可以写“加减乘除天元地元人元”也可以写“+-x÷xyz”一样——符号系统的确略有差异，甚至个别东西并不存在严格的对应关系；但一切归根结底都还是那么几个简单符号罢了。

“因为”“所以”写成三个点、等于写成=，会改变证明的性质吗？

所以，我从QBasic转到C、又从C转C++``、转PowerBuilder、转TCL、再转C转C++、然后工作需要就用`python`、`bash`、`VBA`、`Delphi`、`Java`、`C#……

框架从谁用谁死的ACE到libevent，UI从MFC到C模拟面向对象的GTK再到Qt、WPF再复古到ncurses，从脚本封装glusterfs到深入TCP协议栈玩链路聚合……

拿起来就玩，玩过了就忘掉，就这么简单。

「你学错了方向」

正确的学习目标

学C、学C++``、学Java`，学习目标应该是：

• 自己写libevent
• 自己写玩具版unreal
• 自己写模板程序
• 自己搞类似spring的中间件
• 自己写设备驱动/操作系统
• 自己实现TCP协议栈
• 自己写DSL解释器

……

这些其实很容易。本科专业课内容而已。

一旦你往这个方向训练自己，那么换语言就是换一换符号风格，没什么大不了的。

思路就是那么几条，模仿、遍历、分治、动态规划……；

手法就是那么几种，缓存、索引、信号/事件、回调/消息循环/dispatcher……；

注意事项就那么几点，边界值、等价类、数据完整性原子性、死锁、空转……

这寥寥十几、几十个知识点，玩好了，玩精了，万变不离其宗——几十年了，哪有什么软件/算法能跳出窠臼的？

学什么调优啊。这软件我都会写。知道内部算法，看一眼参数就知道是调整什么的、调整后会造成哪些影响——真不知道稍微一查也立刻明白了。

学什么框架啊。这思路我看了就懂，就知道怎么写。我觉得这个框架我应该这么写、这么给人用，一看果然是，哪有什么“学习负担”——猜错了？猜错了说明基础知识掌握不过关，赶紧补课去。唰唰补足短板，以后就再也难不倒我了。

如此反复训练，自然学什么越学越快、猜什么越猜越准——随便什么技术，内行一看，都是新瓶装旧酒！

那能不轻松吗？

从“术”到“道”

这就是我说的“学什么一定要学根”，“学了根，枝枝梢梢会自己长出来”——千年古树规模很大？就一根树干。

反之，你去学什么spring什么j2ee什么tomcat，甚至具体到apache的配置、Windows10的某个配置改注册表的哪里——不去学根，专去学这些枝叶，那的确是见效快、学了就能用就能人前显圣……

结果呢，Windows7你会了，Windows10来了；Windows10好不容易跟上了，Windows11又来了……

累死你，你都跟不上变化。

换句话说，正确学习编程的方式是：随便学习一门编程语言，然后用这门语言尝试实现数据库、操作系统、网络协议栈、编译器等等等等。

如果你是这么学的，那么你才真正掌控了计算机——将来的任何技术，你都不费劲。

举个例子

比如，这是Android的系统框图：

假如现在我所在公司造了台Android手机，做出来后不知为何，字体显示总是有问题。怎么处理呢？

如果你从梢上学，看到的是一屏一屏类似这样的东西：

几百个屏幕通下来、乱七八糟一通乱试之后，连“总是有些糊”的初始版本你都回不去了。

但换一个从根上学的，很简单——所有字体都糊，那么这个问题就只能往中底层找；Android啊，下层不用管，Linux内核，很熟悉了；字体是freetype这块负责的、然后给display driver渲染……

freetype工作一直很正常，我们也没碰过；唯一的差别是我们的手机和别人相比，用的这块屏幕比较高级，不是简单的条状RGB点阵，而是RRGB四方点阵，并且多了个亮度通道，允许控制单个区域的背光亮度、从而完美支持HDR；

所以问题根源可能是这玩意儿的驱动可能没有优化好，机械的把字体转换成屏幕点阵显示出来，这就造成了字体边缘看起来不光滑、不锐利……让我验证一下，看看这块屏在Linux和Windows下是否也有同样的表现。

一旦确定了问题所在，那就可以找厂家要求升级驱动、或者干脆要来驱动源码、优化它的渲染过程……

类似的，各种框架，你从梢上学，海量的问题配海量的配置参数，慢慢背吧。

但你从根上学，就那么一个框图——我们现在的业务会有若干访问极其频繁的热数据，这些数据最好缓存在内存里。嗯，框图上说它有个“内存数据库”，找出来用用看：问题解决。

再来个例子

我甚至干过这种事：当时用的一个框架，文档极少；我们急需一个功能，我说这功能不难我来。于是花了一个月，自己写程序搞定了。上线后工作良好。

然而忙完这个后，某天我顺着某个关键字追下去，突然发现这个功能是框架本身就提供支持的——这个支持当然比我花一个月匆匆写出来的解决方案完善得多。于是我找经理，打算改用框架支持。

谁知一测试，我那个方案虽然仓促、简单，却恰恰因为它的简洁而有很好的性能；框架那个呢，我得关掉它的很多功能、关的和我的方案差不多才会有同样的性能——当然，哪怕关的差不多了，它仍然是比我那个一个月的东西功能更完善。

经理说算了，别折腾了，就用你那个。我们并不需要那些额外的功能。

你看，我随手就能撸出来，自然找到就会用、就能把它的一切摸透——相比于你这样直接学习框架本身的，我也就迟了一个月而已；而且只要你敢提相关关键字，明天我就能超过你。

而你想学会用它，一个月未必够用。费尽心力学会了，你也只是学会了玩弄一个黑盒子上面的几十个不同旋钮而已——而它在我面前是白盒。

于是，你学Android，需要一寸厚的书看上十几本，这才知道它的网络该怎么配置；遇到实事一番手忙脚乱，还是不知道哪里出了问题、写出的程序老是不正常。

而我呢，就看看它的框图、需要做什么再看一下相关的那个框框的接口风格，够用了——功能不正常？那是。人家说好了是异步调用，完了用消息通知，所以我直接搞了段代码接住消息、然后分发给相关模块——这些模块自然也从一开始就设计了相关机制、考虑了刷新时机。

你呢？当普通函数调用，调了就不管了，那怎么能成。什么？哎呀别死记硬背我的代码，你得明白机制……不是，这个机制不光是框架的机制，还有配合框架机制的我们自己的机制……

对我们这些习惯自己实现的，一看接口入参回参，马上就知道这是什么机制、我们得怎么设计程序来配合这个机制；而你呢，就得死记硬背我们随机应变出来的套路。这就使得你的学习负担加倍又加倍。

你很勤快，一个个库一个个API学的刻苦又细致；

而我很懒惰，比如Android我就只看一个框图看一个intent机制一个activity，看完写个程序试试手，扔下，忘掉。没用。

那些具体的东西，什么spring、j2ee、lamp……不好意思，这玩意儿我从来都不看。

它们的根底我清清楚楚，需要时看看框图、直接拿来用就行了。没事看它们干嘛？浪费时间。

但我掌握了编写这些东西的基本思路，所以哪怕只看了这么一点点，但只要工作需要，哪块出问题我就能对付哪块——报一个关键字，当天就是专家。

相应的，PageRank算法出来了？有了个不同于关系数据库的、新的数据存储思路叫big table？看看看。新思路太难得了，不看就要落伍！

不光要看，还要分析它的灵感来源、检讨自己为何就没有想出类似好主意、还有哪些领域也可以应用类似的思想优化解决方案。

你勤快的学习了一个个API、一个个惯用法，却全都知其然不知其所以然。所以你疲于奔命、却总是跟不上变化。

海洋里有无数条鱼，每天也有亿万条鱼出生、差不多同样多的鱼死去。所以我不需要认识它们，那纯粹是浪费时间。

我只要知道渔网有多少种、有没有人又发明新的捕鱼方法了，这就足够了。

遗憾的是，计算机发展太慢了。这么多年，也就PageRank、bigtable以及深度神经网络有点新意，其他的，不都是新瓶装旧酒吗。

你多花点时间在渔网上，少花点时间在鱼身上，自然就不至于“耗尽所有”还是什么都没学到了。

后记

卡颂：道理我都懂，可是天天加班的打工人，哪有时间学底层啊？

参考资料

[1]

invalid s的知乎回答: https://www.zhihu.com/question/485917018/answer/2216877333