15.1.29
以前沒接觸過專案移植的工作。之所以會有移植是因為我們自主開發的底層平台變化了，底層平台從3.2一下子跳到了5.0，從版本號看得出來這是一次巨變，所以直接導致以前的做過的專案無法使用，但客戶不會管換架構的問題，這是軟體公司內部的事情，客戶要的就是和之前一樣的結果，如果錦上添花也可以，但不會給你一分錢，說到底移植是軟體公司自覺完善自己產品的乙個舉動。移植的專案沒有需求文件，有的只是一攤待的改造的**，開發人員就像翻譯官把日語翻譯成漢語進行一次表面紋絲不動，而裡面風起雲湧的行動。
這個專案是乙個戰例專案（不要問我任何細節），由於是新手所以根本沒有移植的方法，但通過一天的摸索初步總結出來：
0.參考已有的專案功能，任何專案都有相似功能點，裡面涉及的技術自然相同
1.最好找同時熟悉兩個平台的老手做一些技術指導，如：到底是重新做還是基於現有**修改
2.移植主要功能，次要功能可以放緩
3.移植時的核心演算法需要盡可能少的修改，與移植無關的類不要動
4.先移過去，再弄快
5.先移植核心功能
6.盡量不修改對外介面，而僅僅改變內部實現
15.1.30
7.想好對策後就要去做，邊寫邊想才會發現隱藏的更多問題
15.1.31
8.下手幹吧，空想與虛文都是扯淡。。。
15.3.10
9.老平台已有的api而新平台取消，則需要重新對此api進行手工封裝，以此儘量減少對原有**的改動
專案思索點滴
dwater 2005 04 26 2003 年度建議 1 加強對單元測試的重視，鼓勵程式設計師進行嚴格的單元測試，測試 入庫 2 對每個專案安排全職人員扮演 客戶 的角色，捕獲需求 編寫功能測試，進行業務決策 3 整個 系統盡早地 小步驟地整合，以早日暴露風險 穩步前進 4 減小同一專案組相關人員...
專案經驗點滴積累
1.實事求是，不去實踐，永遠不知道事物的真實一面，之前聽別人說公司各種不好之處，如今親身感受，公司不錯，險些誤了這乙個寶貴的實習機會 2.實驗室沒有老師的輔導，自學效率極低，環境很重要 要跟著老師虛心向每一位前輩學習 1.一句一句地研讀專案 不放過一處不懂的地方，細扣！以專案的 來迅速學習 研究別人...
專案經驗點滴 溝通！溝通
還不容易來乙個週末，卻來了臨時任務，結果犧牲兩天的休息日完成地圖模組的開發。難度不大，工作量不小，地圖上幾百個座標點資訊都要取下來。辛辛苦苦到了周一，卻發現專案組內有另外乙個人也做了相同的工作。這不是浪費時間嗎？雖然沒有抱怨等，但如果能提前溝通好，相信這兩位的工作能更好的安排，而不用浪費兩個人的資源...