程序员所积累的编程知识在十年后将有多少变得没用？ 第1页

为什么有 8个人邀请，你们都觉得我很老了么？我还很年轻，悄悄的告诉你们，姚老师比我老，你们该去邀请他。

以前学了现在没用的技术，有很多，越数越伤心，还是回忆下 2007年的事情吧：

1. 业余在玩 Flash 游戏开发，当时页游还没有火，我觉得是个机会，市面上很多页游都是八位机的水平，估计他们以前都没什么游戏开发经验，所以大家都持怀疑态度，我想看看 Flash 的 2D 效果能做到什么程度，于是花了了两周时间做了 Flash 下的第一个小游戏：

Flash Game - Final Weapon 。。。　　

嗯，模仿 PopCap 的 heavy weapon 加了些有趣的元素，比当时所有市面上的 Flash 游戏效果都好一大截，至今为止，仍然有很多市面上的 Flash 游戏没达到这个 Demo 的效果。

2. 带领一只六人团队开发 XBox 360 的预研项目，把公司一套 3D引擎移植到 XDK 的 D3D9下面，D3D8 到9 跨度很大，废了比较多的时间，觉得 D3D9 才是未来。当时 360 的性能并没有说的那么好，单核性能差不多只能到我笔记本单核的 50% 左右，但是它有六个核，和原有引擎的单线程体系差别比较大，因此性能十分堪忧，这个坑填了很久。原有引擎很多基于 SSE 的运算代码全部不能使用了，花了不少时间改写成为 PowerPC 的 AltiVec 指令，最终才将整个引擎终于在 360 上从 “不能用” 变为 “能够一用” 了。当时写了篇关于 360 的优化文章：

PowerPC 汇编入门与优化 。

3. 研究游戏同步技术，当时国内没人觉得游戏还有 “同步” 问题，没有任何参考资料，2007年游戏市场上清一色的 MMORPG 游戏，大家觉得只有做 ＭＭＯ才是挣钱的。我看当时网游里 95% 的 RPG游戏，在对比单机游戏上只有 39%的 RPG比例，觉得十分不合理，玩家迟早要厌烦，RPG垄断的局面必然被打破。但是传统 RPG那一套在快速动作游戏上基本没法行得通。我不断的抓包，推敲模拟传统局域网游戏和国外快速动作游戏的同步方式，写了篇文章：《帧锁定同步算法》配合之前写的《网络游戏同步法则》以及《影子跟随算法》，基本上从两个方向讨论游戏同步的两大核心方法：帧同步和状态同步（客户端预测插值）。

4. 学习策划知识，翻译 MUD之父 Richard Bartle 的《MUD玩家分类理论》，当时游戏“成就系统” 在国外刚刚兴起，国内游戏还没有这个东西，觉得十分不错，我又翻译了 《成就系统最佳实践》。

5. 弄 server 内存分配优化，参考 kernel 的 slab 内存分配算法，于是优化并重新设计了一套 slabtree 分配算法，给服务端整体内存分配性能提升了一倍，不再受运行时间和碎片的影响 。大致原理见：如何设计内存池？ - 知乎

10年后：

1. Flash 基本挂掉了，没人再提了，不过如今页游还是在发展，只是远没当初那么火爆，当年学习 Flash 的程序员都纷纷 cocos 和 u3d了，现在做页游想招聘一个 Flash 程序员更是难上加难，不过 Flash 的 API 我觉得设计的真的很漂亮，我见过 2D 引擎里比较上乘的接口设计了，今天很多用 H5封装的游戏引擎，比如白鹭引擎，没事扫了一眼，他们从对象树到 API名称，还是再模仿 Flash 的接口，可见影响力有多大。

2. 360也挂掉了，当年游戏机清一色的 PowerPC （主机）和 mips（掌机，PSP）架构，如今换成了 x86（主机）和 arm（掌机）结构了。D3D9 也早已被淘汰。　

3. 同步技术到今天都还在很多讨论，作为研究的比较早的人，我的三篇文章曾经帮助了不少游戏解决他们的同步技术。《街机三国》的制作人跟我说，当时做 DEMO就是卡在同步上，后来看到了我的 《帧锁定同步法》解决了《街机三国》的同步问题，最终项目得以立项，然后他们就发财了，我得到一句真诚的 “感谢”。听说《王者荣耀》也还在用基于 “帧同步” 的改良方式。

4. 当年花过好几年的时间学习策划知识，业余也喜欢自己兼任策划和程序做些小游戏，但如今成就系统早已不是什么新东西，巴图的理论也出现了更为科学先进的玩家分类方法的论文，加上 2009 年以后我就不做游戏了，这些知识基本也就白费了。

5. 后来发现和 tcmalloc 很像，用了 7年这套代码，比 libc 自带的 malloc 强太多了，一路都是最好用的内存分配算法，后来我自己忙其他项目懒得添加新特性和继续优化就换成 jemalloc 了。当年 “内存分配” 这个技术，但凡有点经验的人，都会来两手，也是比较关键的模块之一，如今好玩看看就行，自己重新实现边际效用太低。

----

总结下，翻翻历史，以前学过现在没用的技术实在是一大把，我承认技术是有 “道” 和 “术” 的区别，我写了十多年代码的时候以为 “术” 容易淘汰，而只有 “道” 就能长存，一旦掌握了恒久不变的道，就可以以不变应万变；而又写了十多年代码以后发现从更长的尺度上来看，并没有一成不变的东西。

道法精深，短期是可以帮助你尽快的掌握运用新的 “术” 但是随着具体实践的不断发展，人类认识世界的范围逐步扩大，理论体系这个上层建筑的 “道” 也需要不断修正，推陈出新，适应新的实际情况。

早期基于的端游开发经验，帮我在 Flash 平台上可以更短的时间内掌握要点，并做出超过同期水平的东西。手游兴起后，我虽然没趟这滩浑水了，但看到很多第一批成功的团队，也都是早年在端游或者页游上有经验的人。

另一层面上，道也不是一成不变的：以前积累的各种单核技术下的 “道”，碰到 360 这种 6核cpu，每个核都不行的体系，基本全废了；以前写代码，每一行我都想追求极致性能的做法，后面变得没那么重要了；内存分配算法，在某一阶段内自己可以做到领先，但不能持续了解最新相关方法，不持续迭代，兴趣转移了，隔段时间也就被 jemalloc 超过了，所以也并无一成不变的算法。

总之，基本原理要掌握，不能成天只搞具体技术忽视理论提高；也不能痴迷纯粹的 “理论”，还是要勇于实践掌握新进的 “术” 才能更好的迭代进化你自己的 “道”，否则空有理论，只能坐而论道了。这不，我一把年纪了，最近几个月还在玩 beautifulsoup4 做爬虫呢。

并没有什么 “一成不变” 的 “基本原理” 可以让你学一次就吃一辈子的。

钱学森不是说过么，脱离工程的理论，是没有价值的。

---

你现在积累的知识和技能不要说在10年之后，5年之后都未必是有用的。但并非只有程序员是这样。

还记得之前知乎就有过一个工作被机器取代是如何一种体验。大家说了很多过去的，现在的和未来的例子。社会在进步和发展，那当然过去的知识和技能会慢慢落后于行业和整体社会的发展，这是非常正常的事情。医生，律师，水管工，英语老师也同样需要不断学习新的东西，积累经验才能提高自己。

但为什么程序员觉得自己的技能需求变化尤其之大呢？因为行业发展的速度太快了啊。程序员之前会这么觉得，最主要是现代软件工程的发展速度实在太快了，需求上升实在太快了，发展速度快，自然旧的一些技术知识和技能点会被淘汰掉。

有没有一些不会被淘汰掉的呢？当然，旧的技术细节容易被淘汰掉，但是计算机科学和软件工程的核心思想，理念和理论是不会淘汰的。除非出现了极为跨越式的进展，彻底革新了这些核心的思想和理论。在某种程度上说，近些年的软件工程变化也是有一定本质上的，主要原因是硬件的发展使硬件成本大幅度下降，软件的需求大幅度增长，对工程师协作开发大型软件的要求大大提高但实现细节越来越弱化。这在某些领域可能是本质性的变化。

这还只是在传统软件工程领域的发展带来的变化，机器学习现在的跨越式进步，主要是深度学习带来的，真正全方位影响社会的时候还没真正开始呢。VR/AR对整体社会的全方位影响也还没有真正开始呢。机器人技术各方面取代和增强人类才刚刚开始呢。医生不需要学习新技术吗?手术机器人不需要去学习如何操作互动吗，AI诊断不需要去学习如何利用辅助吗，增强现实辅助手术不需要去学习吗。

当然，话说回来，程序员要学的东西可能更多，变更更快。但这是因为站在风口浪尖上，这是好事不是坏事。因为很难碰上“系统性风险”，比如普通工人面对工业机器人，司机面对自动驾驶，翻译面对机器翻译这样无可奈何的事情。程序员只要持续学习总有东西可以学习，总可以进步随着世界一起发展，但一个高技术工人，有一天被工业机器人取代的时候，他再愿意努力，又哪有努力的方向呢？

最后，程序员最好是系统性的学习整个体系，培训班培养出来的还是很容易被淘汰，因为那些往往只学习到了具体的技术细节。科学，工程，技术，事实上是三个领域，不好好学习计算机科学和软件工程的话，在计算机这么个日新月异的领域，技术细节很容易被淘汰的状况下，必然会无比忧虑。你看科班出身的人大多不觉得技术更新换代是什么坏事情。