一次大項目上線的總結與思考

最近經歷了一次規模不算小的項目開發與上線，事後感觸頗多，有成就感，但也有很多經驗和教訓，總結記下以備後用。

注：考慮到保密問題，有些細節寫的很模糊。

1.與舊有系統的兼容性

本次開發的這個項目主要是將舊版系統徹底升級(重寫)爲新版系統，可是因爲不少數據是經過舊版系統生成，因此新版系統上線後產生了數據兼容性問題。

(1)在測試環境下全部菜單中文沒有什麼問題，然而上線當天晚上，文件打包發送到服務器上後，發現全部中文變成了亂碼，不得已，數十個模板只好一個一個手改，好在不是不少，每人分了幾個很快搞定了，但是過後在想，若是當時更多中文菜單出錯怎麼辦，並且在那種情景下，再進行大規模文件更改很容易致使出錯。後來發現，是因爲測試環境和線上環境的編碼設置存在差別，而開發時候沒考慮到這第一點纔出現了這樣的問題。

(2)第二個問題(該模塊由本人負責開發)是因爲原來的系統是一款著名的cms,如今新的系統再也不使用，然而該CMS的內嵌富文本編輯器在處理單雙引號實體轉義方面有些瑕疵(也可能因爲咱們使用的版本較早)，早期由該編輯器編輯的文本數據經過新系統中新的編輯器顯示後，標籤沒有被解析，實體被原樣輸出。

總結：遇到新系統升級類型的開發的時候，必定要充分考慮到新舊系統的兼容問題。

2.業務需求模糊不清

曾經在某程序員論壇上看到一則博客，說的是程序員是否須要學習所在領域的業務知識，如今工做了近一年，結合本身的親身經歷，對這個問題的回答是：必須須要，並且很重要。中國的軟件開發企業主要仍是應用開發居多，而應用開發是必須結合具體的業務場景的，若是連本身開發的模塊的業務流程都不知道，怎麼去作開發，不知道what，如何去how，因此從這個角度講，業務流程就是應用層軟件開發中的「算法」。

(1)舊版系統向新系統遷移時，後臺管理模塊有些字段和功能須要裁減，但因爲業務不清楚，裁減過程當中出現了不應去掉的功能去掉了，能夠去掉的沒去掉，致使階段性會議評審中被反饋返工修改，對工期形成了影響，只能經過加班完成。

(2)最近隨着互聯網興起，敏捷開發也如火如荼地在各個企業被「採用」，然而，在這之中的大多數狀況是「畫虎不成反類犬」，敏捷開發強調「重交流，輕文檔」，但是到了具體實踐中變成了「靠交流，不文檔」。形成的後果就是項目中切入新手，就須要花大量實踐去經過閱讀代碼等低效率的方法熟悉業務，同時新手對組內老成員的詢問(主要是業務上的)頻繁打算其思惟，這是很煩人的(相信你們都有寫代碼時候被打斷的狀況，那個感受就很少說了)，再進一步，完美、高效的溝通也許能夠替代書面，可是縱觀程序員這個羣體的溝通能力，呵呵。。。。。

總結：業務中能夠多交流，可是該有的文檔仍是應該要有，尤爲是相對而言變更較少的業務流程，仍是應該文檔化。

3.工期安排

(1)整個開發過程當中穿插着階段性評審會議，會後可能會對根據評審對模塊進行反饋式修改，這樣就會致使工期延後。

(2)整個項目中，一樣一個模塊，對於熟練的老手和新手所須要花費的時間是不一樣的，所以在安排工期和分配任務時須要考慮。

總結：安排工期不該當僅僅按照模塊一個接一個安排，每一個階段中應當留出冗餘時間來應付工期自己的進度變動。

4.上線環境和測試(開發)環境的一致

(1)新系統有一個功能模塊，是手機發送下載功能，同事在開發這個功能時，測試環境居然不能進行短信發送，也就是說，驗證碼發送下載這個流程沒法進行上線前測試，沒辦法，只好在腦子裏進行流程測驗，仔細審查了全部代碼的流程，最後上線前自信滿滿認爲不會出問題，結果當晚上線這個功能沒法正常使用。。。。。。。。

(2)前面說的亂碼問題，因爲線上的數據和測試環境的數據不同，測試環境不少靜態資源沒有，結果在單元測試的時候也沒有發現圖片沒法顯示和亂碼問題，結果上了線出問題了。

(3)測試。有些公司感受對測試的重視仍是不夠，許多測試都是形式化的走一遍流程，更不用說什麼邊界測試等等，而程序員單元測試的時候，老是傾向使用「乾淨」的數據，使得問題沒法被儘量多的被暴露。

總結：測試環境從佈局、數據到軟件版本，都應該和上線環境儘量相同；單元測試的時候應該儘量詳細，若是時間條件容許，組員之間能夠進行交叉模塊測試。

        此次上線學習了很多，既有技術上的也有非技術的，總結下來之後常常複習思考，避免下次上線跌倒在一樣的地方，同時隨着工做經驗的增加，文中有些觀點可能還須要進行修正和補充，歡迎你們提出寶貴的意見。