外包公司作遺留項目有意思麼？

過年後，在目前公司的工做就要告一段落了，又恰逢年終，終以爲仍是要總結點什麼，來個了斷吧~

背景介紹

考慮了一下，彷佛技術上沒有什麼太多可說的，再加上外包項目也不能透露太多客戶的東西。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開始，但別拿這個當終極目標了。。 咱要有長遠打算。

還無聊嗎？ 我不知道啊！

 那好，說了這麼多，就是讓那些迷茫的人，能在本身的組織結構裏，本身可控的部分挖掘潛能，畢竟，沒人能阻止你進步。