為什麼新技術推廣難

今天和大家聊聊過舊技術的問題，這個名詞聽起來挺怪，技術本身無罪，最後想了想，還是暫且這麼標記吧。

我想起了在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萬事大吉，對於開發而言，更是一種福利，你說升級以後的效能影響有多大，如果業務本身簡單，這個風險幾乎可以忽略不計。

當然最後一種情況就是行業裡大家都在用，我們不用似乎就是慢了，落後了，為嘛，先用用再說，還有更多的說辭。

我覺得有時候過舊的技術和新技術就是一把雙刃劍，沒有絕對的好，也沒有絕對的爛，最佳實踐有時候就是隔著那麼一層窗戶紙，成為第一個吃螃蟹的人很難，願意冒著風險去探路的都和難得，很多人的態度其實都很明確，我支援它，理解它，但是我不能用，等它變成熟穩定了再用，如果大家都這樣想，很多技術本身就很難普及開來。技術人的話語權有限，有些人分身乏術，有些人為了求得自保，什麼事情都有兩面性，技術更是如此，要麼因為簡單而被替代，要麼因為複雜而被革命。