为什么新技术推广难

　　为什么新技术推广难，今天和大家聊聊过旧技术的问题，这个名词听起来挺怪，技术本身无罪，最后想了想，还是暂且这么标记吧。

　　我想起了在8年前的一天，一个很资深的前辈在聊到自己的感触的时候说，技术的更新在实际工作中总是会慢一拍或者几拍。比如Java,当时的通用版本都是1.5，新的版本都是1.6了，但是工作环境中却清一色是1.4甚至更老，而且短期内也不会计划升级到最新版本。而这后面的原因其实也是复杂多样，我可以简单来聊聊。

　　过旧的技术可能就像一个有点懒癌的人一般，总是慢一些，不与时俱进。就想Hibernate的延迟加载，就像Oracle中的延迟段创建，总是运行时才开始忙起来，现实生活中好像我就是这样的人，总是在事情的紧急关头才开始忙活起来。

　　老旧的技术有几种境地，一种是维持现状，因为够用，第二就是不更新则已，要更新就来大版本的。第三就是直接被毙掉，用新的产品或者轮子替代。我看到的很多技术的生命周期就是如此，很少有循序渐进的。

　　先来说说维持现状这种情况，虽然听起来是老旧的技术，但是完全够用，这种实在没有任何动力去更新，或者说更新的代价还不如重新写一套。

　　举个身边的例子，一个是很早的一个产品，甚至数据库都没有用现在主流的，而是当时开发自己完成的，可以说自己写一套存储方案，当时想想简直就酷毙了，现在回头想想这样的产品怎么能活到今天，而现实的情况是这个产品依旧很火，虽然不是很牛的一个产品，但是已然达到预期，可以养活一个很大的团队的开支，所以公司也持续投入人力支持，保持着这样的发展。我想以后也还是会这样保持下去。另外一个产品，也是公司的开发团队，他们自己搞定了一套web框架，竟然完全实现了大家熟到的各种web框架，所以用了很多年，所以一直以来就没有过升级软件包的需求，因为都是自食其力。这种情况可能确实比较少，但是都发展的很好，让人肃然起敬，如果你跳出来说升级，就好像你是裸奔的人一般。

　　第二种情况是大步快走，更快更强。身边的例子着实不少，记得一个早期的产品使用的是spring 1.0版本的框架，在早期的产品中确实是有了深远的意义，但是产品发展的越快，需要的功能和需要解决的问题越多，原来的很多问题就不得正面应对了，而解决方案大体就是大版本升级，而这个过程对于一个成熟的产品来说，风险很多，而且最要命的一种风险就是不知道哪里可能出问题，而一旦放大到了线上的某一个阶段，越晚发现代价越高，所以这个过程本身就会耗费大量的精力，就是为了达到兼容和平滑过渡，所以不鸣则已，一鸣惊人，直接升级到spring 3.0。里面涉及的兼容问题实在是不少，虽然没有亲历这个过程，但是初期的梳理工作就让人很糟心了。再来说说数据库的事情，很多数据库版本可能落后市场有5年以上，比如Oracle数据库的大版本几乎是6年一个周期，所以现在主流的版本就是11g,而12c却迟迟未出，6年对于一个技术更新来说肯定是一个很长的周期了。下面是之前找到的某一年的数据库版本的调查结果，当时清一色都是10g，

　　现在呢，几乎已经看不到这类有些古董的版本了。如果你使用sqlplus "/ as sysdba"那肯定会被人认为你是从9i的年代过来的，直接就暴露了年龄。

　　第三种就是被替代，用心的产品或者新的轮子代替。

　　这类情况简直不胜枚举身边的一个大项目，已经用了很多年，一直也没出什么问题，这就是第一个阶段，但是后面还是有很多功能的限制，所以需要改进，当时使用oracle 8的数据库,而当时的主流版本依然是11g,所以直接是用8升级到11g,这就是我说的第二阶段，而数据库的升级可能是系统变更中的一个很小的方面，业务层面其实有更多的变动和扩展，结果就是需要一套新的系统来替代旧的系统，这也就是我所说的第三个阶段，直接被替代，当然这个过程简直非常艰难，光测试就差不多持续了近一年，然后分批迁移，总算是完成了这个艰巨的迁移。

　　而新技术相比于过旧技术总是看起来有更多的话语权，新的大多数都很好，新技术在什么时候容易引入进来，我想了想有这么几个方面。

　　1）被当前碰到的问题折腾的筋疲力尽；

　　2）在紧急关头，别无选择，死马当活马医

　　3）能够被透明的应用进来，无感知。

　　4）大家都在用

　　这种情况更是让我想起了很多的故事，技术问题总是有很多的改进之处，哪怕它现在看起来已经足够强大，但是还是有很多的事情需要补充。

　　如果当前碰到了很多难以忍受的问题，比如碰到了一个就版本的问题，你已经被折腾的灰头土脸，每隔一段时间就需要重启服务器等等，补丁不管用，软件开源，新的改进还没有发布等等，那么新技术可能会自然而然成为你的选择，如果刚好能够解决你的问题，简直让你忍不住说perfect，如果运气不好，可能另一种情况是你又掉入了另一个坑。

　　如果一个问题目前来看很正常，一旦出现问题，变成了紧急问题，在现有的问题解决不了改进不了的情况下，如果你有详细的测试和准备，你可以很轻松得到这种信任的门票，在别无选择的情况，死马当活马医，一旦成功，那就让大家刮目相看，如果没成，对你似乎也影响不大。

　　如果问题能够透明的被解决，那和你合作的人会更加的体贴合作。比如Oracle的ADG。我们可以在一个数据迁移的需求中，借着这个需求来升级数据库，如果本身这个数据库有大量的报表查询业务，每次都得你开个只读窗口在备库设置，结果升级之后有了ADG万事大吉，对于开发而言，更是一种福利，你说升级以后的性能影响有多大，如果业务本身简单，这个风险几乎可以忽略不计。

　　当然最后一种情况就是行业里大家都在用，我们不用似乎就是慢了，落后了，为嘛，先用用再说，还有更多的说辞。

　　我觉得有时候过旧的技术和新技术就是一把双刃剑，没有绝对的好，也没有绝对的烂，最佳实践有时候就是隔着那么一层窗户纸，成为第一个吃螃蟹的人很难，愿意冒着风险去探路的都和难得，很多人的态度其实都很明确，我支持它，理解它，但是我不能用，等它变成熟稳定了再用，如果大家都这样想，很多技术本身就很难普及开来。技术人的话语权有限，有些人分身乏术，有些人为了求得自保，什么事情都有两面性，技术更是如此，要么因为简单而被替代，要么因为复杂而被革命。