软件技术及相关问题的变化是发明创新、公司产品运作、社会市场需求消费、人才资金循环、政策法律等等整体运行中的一个小部分，其发展过程将受诸多因素的影响，但其自身也是有一定规律的。作为行业中具体干活的人，面对这个技术日新月异的行业，琢磨一下行业未来 30 年的某些事情。

　　30 年后的事情不用考虑了，就算想清楚也没用了。

　　30 年内的软件技术及相关问题分为变化不大的和变化可能比较大的。变化不大的学会了用熟了会终身收益，变化大的要及时把握参与深度。

　　一、变化不大的

　　1. Intel x86 的指令集

　　原因很简单，如果这些指令集发生重大变化，那这行业开发、积累的软件都不能运行了，变化成本太高。

　　即使从32位发展到64位、128位，指令集的兼容是可以预见的。

　　2. 操作系统 - 启动过程

　　系统加电复位、硬件自检、操作系统引导、内存管理、进程管理、硬件中断处理、操作系统其它部分引导、用户 Shell 引导等这一套流程应该不会有大的变化。

　　3. 操作系统 - 内存管理

　　i386 的三层内存管理模式现在还看不出有多大的变化趋势。操作系统的内存管理模式、API也不会有大变化。

　　4. 操作系统 - 进程（线程）及其调度

　　只要操作系统内程序的运行是通过时钟中断或其它软硬件中断进行调度，那么进程是操作系统调度的基本单位。如从某一天开始“独立的二进制组件”成为操作系统的基本调度单位，那可能更多的是进程控制块的变化。“独立的二进制组件”的加载本身很可能就是进程。

　　5. 操作系统 - 文件系统 API

　　文件系统可能会不断变化，但文件系统的 API 应该不会有多大变化。

　　6. 数据库 - SQL 语言

　　关系数据库的理论与产品技术已经非常成熟，对维护到现在已经保存的大量数据而言，SQL 语言是很难被替换的，XML 可能将会与 SQL 合作而不是替换。即使对象数据库理论及产品成熟了，SQL 肯定将被兼容。

　　7. 网络浏览的协议与格式 - HTTP、HTML、Javascript

　　就算大家对 HTML 再不满意，其修改、进步的步伐也不会很快，太多的信息内容保存成这种格式了，变化的成本太高。

　　HTTP 是与 HTML 相伴的，变化不会太大。Javascript 更是如此。

　　8. 电子邮件的协议与格式 - POP3、SMTP、MIME

　　POP3、SMTP、MIME 也已成大规模，变化的成本很高。

　　9. 网络协议 - TCP/IP 族

　　IPv4 到 IPv6 是可以看到的，但 TCP/IP 的基本结构及 API 应该不会有多大变化。变化的成本太高。

　　10. 微软的Windows - Windows

　　除非连续发生重大经营失误，否则微软是不会简单倒下去的，关于这个主要不是技术的问题，不多说。简单认为 Windows 会存在很长的时间。

　　Windows（产品） 中的 Windows（窗口技术）是精华，已经很成熟，其相关的 API，包括 GDI、消息机制、Common Controls等不会有太大变化。就算以后以组件的形式出现，那也只是 API 的另外一种形式。

　　11. 微软的Windows - DirectX

　　只要老百姓还在用 Windows，那么 DirectX 作为游戏的开发平台会长期的保持下去。

　　12. 开源组织与 IBM 的 Linux - Shell、XWindow

　　开源组织现在看不出任何的前景衰落，IBM 已经发展了百年，他们联合推动的 Linux 再活 30 年应该没问题。其基本的 Shell 与 XWindow 结构不会有太大变化。

　　13. OOP 语法与思想

　　编程语言是编写逻辑、调用 API、解决问题的工具。其中的 OOP 语法现在方兴未艾，引导了编译器、虚拟机、API 都向其转变。若干年后，即使编程语言又发展革命了，OOP 很可能将作为其基础。

　　14. 算法

　　可以说是数学的一部分，包括纯数学算法与应用业务逻辑或应用算法。解决问题的算法的生命力是永远的，独立于系统、编程语言。即使我们研究不出来新算法，但掌握某些算法是应该的，这是掌握基本软件开发知识后的长远竞争力之所在。

　　二、变化比较大且影响比较大的

　　1. 产品外观、用户操作界面与交互方式

　　产品外观、界面与交互方式的变化永无止境。像微软这样的公司在这方面投入巨大精力。实际上这是给老百姓看的，不是给开发人员的，但在很大程度上会影响开发人员的产品外观设计、界面设计及交互设计。

　　2. 编程语言、编译器及其支持库、虚拟机

　　具体的编程语言与编译工具的选择使用是程序员、开发部门自己的内部事务，一般与系统API、产品市场需求、开发结果等无关。影响编程语言与编译工具的选择使用的因素非常多，变化性很大。就算一个编程语言或其相关的编译工具的生命周期很长，但也很难保证被一个开发团队长期固定使用。过度沉迷进而局限于某个编译工具的风险很大，但不钻研到一定深度很难做出来好东西。

　　3. 开发管理模式

　　不同的产品、项目，不同的应用平台，不同的编程序语言，需要针对性的开发管理模式。即使使用相同的 OOP 语法的编程语言，针对不同的产品或编译工具其开发管理也是不同的。开发管理其实是组织开发人员利用编程语言写出结果的过程，当然应该不断地进行调整。有一些粗线条的管理理论只能进行指导，真正的实践是另一回事儿。

　　4. 开发技术的应用需求

　　随着软件应用平台厂商、开发工具厂商的不断的产品升级、市场推广活动，以及社会消费热点不断的变化，市场客户对开发技术的需求不断地进行调整。