外包公司做遗留项目有意思么？
過年后，在目前公司的工作就要告一段落了，又恰逢年終，終覺得還是要總結點什么
背景介紹
考慮了一下，似乎技術上沒有什么太多可說的，再加上外包項目也不能透露太多客戶的東西。3年多做得都是同一個Account（客戶）下的項目，是客戶產品線下的一個數(shù)據(jù)中心產品，面向數(shù)據(jù)中心的基礎設施用戶，也就是國內IDC。產品提供數(shù)據(jù)中心IT基礎設施運維整體解決方案， 屬于行業(yè)內KVM交換機頂級品牌， 另一家也是美國廠商, 行業(yè)內剩下的就是國內中低端的深圳廠商， KVM over IP 還是較有技術含量的。
該產品有悠久的歷史，最早的代碼在源碼中的標記是10年前， 那時java還處于一個嬰兒期， 并沒有這么多開源框架支持企業(yè)級開發(fā)， 數(shù)據(jù)模型還是用java bean封裝，操作方法也在bean中， web層的調用直接穿透到持久層（也就是bean）這里。so，這樣的東西有技術挑戰(zhàn)么？
遺留項目到底有沒有意思？
大部分程序員都喜歡搞新項目，覺得新項目不用吃別的程序員的"狗食"， 能大膽用新技術，很爽。但現(xiàn)在IT信息化已經進行了10幾年了，如果是外包行業(yè)，基本上接的最多的項目肯定都是維護性項目， 一般企業(yè)哪有這么多新項目啊，都是遺留系統(tǒng)。
遺留項目自有它的特點， 首先要吃透該系統(tǒng)的整體技術設計， 至少是宏觀上的層面要有個整體把握，然后才能根據(jù)客戶的enhancement需要來設計，不要破壞已有系統(tǒng)的設計，偏離了原來架構的設計意圖，會使軟件越改越爛，就是重構那本書里提到的"bad smell"。一旦有這個趨勢，要及早處理， 這個技術債越欠越多，維護的人員一批一批的換，到最后沒人搞得清楚整個系統(tǒng)的runtime運作，有些公司老產品折騰不來了干脆推倒重來， 然后循環(huán)又開始了。
這個就是維護的技術含量了，聽說還有個專門的行當叫維護架構師，國內公司似乎還沒發(fā)展到這個程度。你需要在遺留項目定好的條條框框里輾轉騰挪，使勁渾身解數(shù)，為了提高產品的一點性能，應付越來越多的數(shù)據(jù)，保證質量的同時，盡量引入當前比較主流的工具或方法學來提高團隊效率。
我們的項目就經歷過一次大幅重構：
數(shù)據(jù)庫從PointBase內存數(shù)據(jù)庫更換到主流開源庫Postgresql
引入Ioc（Guice）
基于原來的bean方式簡單操作重新用JPA封裝了持久層
由于原來內存庫在數(shù)據(jù)量不大時速度如飛，更換了常規(guī)文件系統(tǒng)數(shù)據(jù)庫后必然影響性能，所以加了ehcache緩存，對sql中where語句的查詢結果進行緩存
2011年時部分復雜操作頁面改用富客戶端的Flex來處理，提高易用性（那時Adobe還沒有放棄Flex）
高可用：每個WebApp之間的數(shù)據(jù)庫采用開源方案SymmetricDS來處理，支持異構數(shù)據(jù)庫同步（雖然當前不需要）
還覺得無聊嗎？也許。
對于大部分項目機會不能自己選擇的業(yè)內同行，也許有意思的玩意就在你身邊，你覺得是一坨shit的東西仍然能從系統(tǒng)的整個生命周期中，結合當時的技術環(huán)境，看到這坨shit的一些有意思的東西，從設計文檔里體會當時的設計權衡，考慮。 當然，文檔里只有設計的結果，有些妥協(xié)maybe只有當事人才能知道，but,這不是重點！ 這里只想說，一個人想提升自己，如果有心，任何時候都可以，只要會發(fā)現(xiàn)。
OK，這是enhancement，那bug fix呢？這個更簡單，現(xiàn)在如火如荼的開源，所有人去參與一個項目的第一步是什么？
看項目介紹，找架構文檔，有個初步認識
訂閱maillist，在里面渾水摸魚，繼續(xù)了解項目
去項目的online bug tracking上看看，有啥自己懂得沒
然后。。。 改bug去吧~ 混個臉熟吧！ 多改幾個吧！ 改著改著， 哇！ 核心開發(fā)啦！
多么的相似。菜鳥都從改bug開始，但別拿這個當終極目標了。。 咱要有長遠打算。
還無聊嗎？ 我不知道啊！
那好，說了這么多，就是讓那些迷茫的人，能在自己的組織結構里，自己可控的部分挖掘潛能，畢竟，沒人能阻止你進步。
總結
以上是生活随笔為你收集整理的外包公司做遗留项目有意思么？的全部內容，希望文章能夠幫你解決所遇到的問題。
