這段時間一直忙於一個專案的歷史資料遷移，這期間遇到的問題千奇百怪，可以說杯具是接二連三。現將這些問題簡單總結一下：

第一個問題：不知道老系統的資料庫結構和程式碼的結構，客戶只給了我們一個執行包和dmp檔案，一下子不知道如何還原老系統的環境，在糾結中不停的百度，

後來通過Reflector.exe工具將原來的檔案進行反編譯，漸漸的對裡面的程式碼進行分析，搭建環境。

第二個問題：不知道資料庫中欄位的含義，現在想想都覺得噁心，資料庫欄位命名竟然採用XX1，XX2,xx3的方式，並且沒有一句註釋，當時就特痛恨之前的那些開發人員，怎麼就不為後來的人著想呢（軟體開發中的備註真是不可缺少啊），為了將資料庫欄位與頁面中的欄位的進行對應，這項工作折磨了我好幾天，只能通過頁面上的值和資料庫中的值進行比對，從而去判斷資料庫欄位的含義，並且把這些欄位新增備註。（當我把這項工作搞完時發現已經可以重新把原來的資料庫重新設計一下了）

第三個問題：新老系統的如何進行對應？雖然使用者也很熱情的給我介紹相關的業務邏輯，可是悲催的是新系統的資料庫也不是我設計的，（後來才參與這個專案的），新老系統的資料庫設計風格完全不一致，而且新系統還增加了很多的新功能，同時也刪減了部分老功能，同一個業務表，新老系統中存的資料也存在著很多的差異。為了向新系統中匯入老系統的資料，我整天就泡在oracle的指令碼中（後來自己都發現很佩服自己，發現寫指令碼的的能力得到了大大的提升，那麼噁心的東西都被整理的井井有條，如此說來只要用心，多花工夫，還沒有解決不了的問題），每一個改動都用指令碼進行記錄（這個經驗以後也一定要保持，在正式匯入時這些指令碼可相當的給力，否則那麼多問題，若是沒有這些記錄，時間久了哪裡知道這些資料為什麼要這樣處理）。

第四個問題：資料雖然匯入成功，但是業務邏輯就是否正確呢？為了解決這個問題，測試的功勞不小，測試能暴露很多的問題，同時也發現了指令碼的不完善性，從而就不斷的測試--完善指令碼--再測試--再完善指令碼……一直到所有的問題都解決，這個過程的痛苦不亞於前幾著，雖然這項工作有痛苦，但是最終當完成整個資料的遷移時，那種喜悅還是覺得值得的。