给技术焦虑者及狂热者的建议[转]

  计算机 技术 在一般人的概念里，是一种变化极为快速的东西。就拿处理器来说，没多久前才推出双核心的版本，四核心随即问世。

对于保守不喜变化的人来说，计算机真的是一个叫人望之却步的领域。事实上，不仅对一般人来说是如此，对许多信息产业的从业人员而言，又未尝不是这么想的。尤其信息产业是个名词快速推陈出新的产业，就拿网络来说，一下子是 Web 2.0 、一下子又是 UGC （ User Generate Content ）、 SNS （ Social Network Services ），想要追赶时代潮流的每个浪头，光是在心中想想，就觉得十分吃力。

技术飞快进展，一不注意就遭淘汰？
可是，转念一想，技术变化如此快速，倘若不能时时勤拭，职场生涯的前途恐怕就要染上些许的尘埃了。将这种「如果不持续关注技术 发展 ，就会被淘汰」的恐惧称为「 新技术 焦虑症」，一点也不为过。有些人甚至相信，对新技术焦虑的念头，是推动自己不断精进的一大动力。

这种 IT 从业人员的毛病，程序人当然也无法免疫。以 Java 为例， JDK 最近几年一路从 1.4 杀到了 1.6 。记得不久前 EJB （ Enterprise JavaBeans ）还大行其道，现在 Entity Beans 早就乏人问津，如今，最多人采用的数据存取方案已经是 Hibernate 了。

Java 不是才流行没多久吗？怎么最近已经有人喊出「 Java 即将 COBOL 化」的口号呢？ Java Frameworks 一堆过时又复杂的设定，让 Java 像是一头脚步笨重的大象，要使用当红炸子鸡的 RoR （ Ruby on Rails ）才能跳出轻盈的舞姿。虽然身在 Java 阵营，但是看着吸取 Java 精华再发扬光大、又有微软一甲子功力加持的 .NET 技术，心里难免不禁心猿意马，不知道是不是应该要预先做好更换跑道的心理准备。

许多程序人深陷在这样的焦虑中，不是耗费许多的时间探索每一项新技术，就是时常让这样子的忧心困扰。事实上，从我的观点来看，这两种情况都大可不必。

紧盯每一项新技术的发展，收获有限
其实，任何领域的知识学问多半有一种共通的特性，也就是说，越是变化快速的，越是位在学问领域的外围或表面；而真正处于核心地位的学问，几乎都是稳定而长久不变的。

以计算机科学的学问来说，一代大师 John von Neumann 提出的冯-诺依曼架构（ Von Neumann Architecture ），至今所有的计算机都无法超出它的范畴。愈是包容广泛且价值重要的学问，其实往往历久不衰且不变。今日信息科技所使用到的理论基础，绝大多数在几十年前就已经建立完成，而且鲜少有极大的变动。

从另一个面向来看，许多人所害怕的那些快速变化的事物，时常都只是短暂的光环，很容易就被其他的事物取代。倘若因为对技术的焦虑，而迫使自己不断地追求每一项新的事物，那么不仅疲于奔命，更残酷的是，其实追求的事物，也许根本一点都不重要。

当 B 快速取代 A 、而 C 又快速取代 B 、发展到 D 快速取代 C 时，从 A 直接跳过 B 、 C 来到 D ，其实并不会有太大的差异。但对紧盯每一项新技术发展、关心每个 A 、 B 、 C 、 D 的技术焦虑者来说，必须投入探索成本可能就高很多了。

善用成熟技术，而非浪费心力摸索
更有一类人，不以追求新技术为苦，甚至以追求新技术为乐，我称为「技术升级狂热者」。这一类的人可以算是技术焦虑的加强版本，他们不仅存有追求新技术的焦虑，而且时常因为技术能力好，上手速度快，也容易从新技术中发掘专属的乐趣，所以总是花许多时间学习新技术，尽可能地应用新技术开发所有想做的产品或服务。

保持对新技术学习的热情，并且还有能力驾驭，绝对是一件好事。可是，典型的「技术升级狂热者」时常会陷入只用新技术的迷思。所以，要开发新的产品前，只挑选最新的技术，甚至会持续把旧有的产品，全部以最新流行的技术翻新。这样的做法其实会遇上两个问题。

首先，从生产力的观点来看，旧有、已完成的产品已经是成熟稳定的，而且满足一定质量标准的。新的技术，倘若不能提供额外的好处，或者不能提供足够多的好处时，贸然更换成新技术，也只是弊多于利。

例如，你已经有一套利用 EJB 存取数据的系统，运行一阵子稳定下来了。不能因为近来流行 Hibernate ，就决定把系统更换成 Hibernate 。即使 Hibernate 或许真能带来一些好处，但是仍得付出探索新技术、以新技术实作、除错解决问题，以及重新让产品稳定下来等代价。除非使用新技术的好处十分明显而且重大，否则轻易更动质量已经稳定的程序代码，通常都是不智之举。

使用新技术还有另一个问题，就是新技术通常相对较不成熟。成熟技术最大的优点，是使用上所有可能遭遇的问题，多半都有人碰过，而且也都有相对应的对策出现。风险不在于新技术不好，而是当你遇上问题时，有可能是全世界少数几个、甚至是唯一一个遇上这个问题的人，没有前人或很难找到前人的经验可供参考以解决问题。

撰写一段程序代码也许很快，但是，当程序代码遇上百思不得其解的问题时，恐怕就得花上几十倍甚至上百倍的时间才能解决它。

待技术有能力存活下来再进场
不论是对新技术焦虑或是热衷于技术升级，其实都应该明白，虽然信息科技万变不离其宗，但是总会有人不断搭配新的观念，尝试推出各种新技术。技术都有一定的生命周期，从被发明、快速成长、成熟稳定，到最后过时。有些甚至撑不到成熟稳定的阶段，就会被淘汰。

有时这是因为技术不够好，不能提供较旧有技术明显的利益，有时也可能是因为市场因素，让好技术无法广为众人接受。即使各项新技术如过江之鲫，令人看得眼花撩乱，但真的能进入快速发展甚至成熟稳定阶段的技术，却又只是众多新技术中的少数。

就好比前文所提及，针对某一项需求，不断有 A 、 B 、 C 、 D 等技术推出。在这几项技术里，也许 B 、 C 都只过渡到快速成长的阶段，就已经被淘汰。如果只是因为焦虑，就得在每个新技术推出后，耗费相当大的心力去探索、研究，那么也许就花费太多时间在不需要了解的议题上，最后也只是镜花水月一场。

不够好以致于被淘汰的技术，就算了解透澈也是一点用也没有。不能广为接受而被众人忽视的技术，使用起来风险也高。事实上，必须要待技术本身证明有能力存活下来，而且足够成熟，你再进场。

熟悉关键知识，效益更大
我的观点是对初发明的技术保有适度的关心，摘要性、重点性地了解它的核心精神就好，这是为了日后在需要新技术时能更快上手而作的基础功课。绝对不需要过度投入，除非只是把这项技术当做一项个人的娱乐。

对于快速发展中的技术，则可以利用小型的实验性项目练习与实验。经过多次的练习后，对于常见的错误或问题，已经能够掌握。等到该技术逐渐成长，快进入成熟稳定的阶段时，便可尝试导入到更大型产品的开发。

最后，我想提供一个忠告，与其焦虑快速变化的表面技术，不如花更多的心力在更本质性的学问上。就程序设计来说，有更多更核心的原则与理论可供钻研。例如面向对象的设计方法、 设计模式 、软件架构设计等，不仅博大精深，而且经得起时间考验，在这些学问上的投资更为值得，也不用担心会快速过期。能够掌握核心，对于快速变化的技术，通常也就能够一以贯之，一法通万法通了。