未来30年软件技术领域的变化预测

不变与变化
服务器君一共花费了481.953 ms进行了6次数据库查询,努力地为您提供了这个页面。
试试阅读模式?希望听取您的建议

软件技术及相关问题的变化是发明创新、公司产品运作、社会市场需求消费、人才资金循环、政策法律等等整体运行中的一个小部分,其发展过程将受诸多因素的影响,但其自身也是有一定规律的。作为行业中具体干活的人,面对这个技术日新月异的行业,琢磨一下行业未来 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. 开发技术的应用需求。随着软件应用平台厂商、开发工具厂商的不断的产品升级、市场推广活动,以及社会消费热点不断的变化,市场客户对开发技术的需求不断地进行调整。

本文地址:http://www.nowamagic.net/librarys/veda/detail/1360,欢迎访问原出处。

不打个分吗?

转载随意,但请带上本文地址:

http://www.nowamagic.net/librarys/veda/detail/1360

如果你认为这篇文章值得更多人阅读,欢迎使用下面的分享功能。
小提示:您可以按快捷键 Ctrl + D,或点此 加入收藏

大家都在看

阅读一百本计算机著作吧,少年

很多人觉得自己技术进步很慢,学习效率低,我觉得一个重要原因是看的书少了。多少是多呢?起码得看3、4、5、6米吧。给个具体的数量,那就100本书吧。很多人知识结构不好而且不系统,因为在特定领域有一个足够量的知识量+足够良好的知识结构,系统化以后就足以应对大量未曾遇到过的问题。

奉劝自学者:构建特定领域的知识结构体系的路径中再也没有比学习该专业的专业课程更好的了。如果我的知识结构体系足以囊括面试官的大部分甚至吞并他的知识结构体系的话,读到他言语中的一个词我们就已经知道他要表达什么,我们可以让他坐“上位”毕竟他是面试官,但是在知识结构体系以及心理上我们就居高临下。

所以,阅读一百本计算机著作吧,少年!

《编程之美:微软技术面试心得》 《编程之美》小组 (作者)

《编程之美:微软技术面试心得》是一本让人着迷的书!阅读起来。有些题目的内容会引起强烈的共鸣,尤其是那些自己非常熟悉并且又深知解答的题目;也有一些题目让我异常惊诧,原来除了我所知道的解答思路之外,还有更好的解答以及更深层次的原因。还有一些题目是从来没想到过的。阅读过程是一次愉快的享受,也是脑细胞持续活跃的过程。

更多计算机宝库...