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