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

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

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

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

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

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

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

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

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

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

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

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

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

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