在六年半的開發(fā)和管理歷程中，曾經(jīng)做過這樣的兩個項目，都是步履維艱、越做越增添無力感的項目，現(xiàn)在回想起這兩個項目，原來有那么多的相似點，而且原來從開始到結(jié)束都已經(jīng)處處透露了危險的信息，只是在初期并未察覺，將危險訊號說出來，讓大家能引以為戒。
這兩個項目的共同危險點是：
（1）二手項目：都是5、6年前開發(fā)完成的項目，新系統(tǒng)的目標(biāo)是用新平臺實現(xiàn)舊平臺相同的功能。
（2）開發(fā)文檔不全：第一個項目之前是C/S結(jié)構(gòu)，使用dephi編寫，只有一份代碼眾多的dephi編寫的源代碼，涉及到業(yè)務(wù)邏輯的部分都封裝在tuxedo中，數(shù)據(jù)庫不用改造，數(shù)據(jù)庫操作邏輯部分依然調(diào)用之前的tuxedo業(yè)務(wù)。第二個項目使用甲方的呼叫平臺編寫，該平臺功能不夠強(qiáng)大，在所有涉及到數(shù)據(jù)庫操作的部分都調(diào)用由其開發(fā)人員編寫的SQL Server存儲過程，可以拿到甲方的文檔有：數(shù)據(jù)庫說明文檔、存儲過程源碼、呼叫流程（發(fā)現(xiàn)已經(jīng)有一段時間沒有同步更新）、簡易的需求文檔。
（3）需求不明確：第一個項目沒有明確的說明文檔，為數(shù)不多的知道這個項目的人也只能說個五五六六，需要通過他們安裝好的C/S系統(tǒng)來了解，甚至要通過源碼來了解。第二個項目有簡易的需求文檔，但年久未更新，而上線的系統(tǒng)卻一直在更新，只能提供不夠完全的參考。
（4）之前開發(fā)人員的流動：第一個項目之前的甲方開發(fā)人員都已經(jīng)走得七七八八，剩下的1、2個知道點情況的人也已經(jīng)是從前任的前任手里接過來的項目，現(xiàn)在沒有正在運(yùn)行的舊系統(tǒng)。第二個項目雖然情況好點，但知道項目總體情況的人也寥寥無幾，但是現(xiàn)網(wǎng)在全國80來個點都有舊系統(tǒng)在運(yùn)行。
（5）都需要變更平臺：第一個項目數(shù)據(jù)庫結(jié)構(gòu)不需要變更，但平臺需要變更，由dephi->Java，我們項目組無人學(xué)習(xí)過dephi。第二個項目之前采用甲方的呼叫開發(fā)平臺 + SQL Server存儲過程，新系統(tǒng)采用我方的呼叫開發(fā)平臺，該項目甲方還需要變更數(shù)據(jù)庫，從SQL Server變更為Oracle，并且有很長一段時間兩套系統(tǒng)要并行，因此不但涉及到要割接數(shù)據(jù)，還涉及到兩邊數(shù)據(jù)庫的雙向同步。
第一個項目從頭到尾都做得苦不堪言：工期緊張（貌似是2個月還是3個月）、項目組成員有幾個是新員工、dephi的代碼被甲方的開發(fā)人員寫得晦澀難懂，周旋于一個源文件4000、5000行的dephi代碼當(dāng)中，而且甲方要求甚多，又不能提供良好的支持，項目組成員被摧殘得“花容”失色，而且經(jīng)過日復(fù)一日的加班加點讓項目組成員流失慘重，經(jīng)過延期、延期再延期，最后不出所料的以失敗收場。
現(xiàn)在如果來總結(jié)這個項目，如此多危險信號的項目就不應(yīng)該簽約，這個項目的如此種種，注定了他是一個鐵定會失敗的項目。甲方開發(fā)人員甚多，有若干Java的開發(fā)人員，卻想交給第三方公司使用 Java來實現(xiàn)，從這里也可以看出這個項目并沒有如甲方前期所說的那樣是個不難應(yīng)付的項目。可惜我等開發(fā)人員常常沒有做不做這個項目的權(quán)利，合同已經(jīng)簽在那里了，只能提供做的過程中的參考意見，sigh……
第二個項目相對要好些，雖然暫時還沒有交付，但是交付的可能性還是很大的，但是現(xiàn)在已經(jīng)延期了2、3月左右，在后期很大一部分開發(fā)工作都放在割接和同步方面，與甲方的存儲過程開發(fā)人員（也是甲方對該系統(tǒng)最了解的人員）J君交流時，我們私下認(rèn)為：“這個項目最大的失誤在于當(dāng)時沒采用同樣的數(shù)據(jù)庫結(jié)構(gòu)，而導(dǎo)致給割接、同步和項目開發(fā)造成不必要的麻煩。” 而這個失誤的造成是由于項目前期雙方?jīng)]有人對割接、同步的問題引起重視，而將精力都放在系統(tǒng)的開發(fā)方面，當(dāng)時由上頭決定了采用新的數(shù)據(jù)庫結(jié)構(gòu)，前期在我方數(shù)據(jù)庫結(jié)構(gòu)出來之前，甲方都沒有提供當(dāng)前系統(tǒng)的數(shù)據(jù)庫說明文檔。
這個項目越到后期做得越步履維艱，為了避免重犯這樣的錯誤，總結(jié)如下，希望涉及到割接、同步、新舊系統(tǒng)并行的朋友開發(fā)時引以為戒：
（1）如果舊系統(tǒng)數(shù)據(jù)庫設(shè)計合理，不要動修改數(shù)據(jù)庫結(jié)構(gòu)的念頭，那將是自討苦吃。因為如果是同樣的數(shù)據(jù)庫結(jié)構(gòu)，即使新舊系統(tǒng)采用的是不同的數(shù)據(jù)庫，割接、同步等都可采用數(shù)據(jù)庫方案，即使數(shù)據(jù)庫層面無法實現(xiàn)，也有很多開源的程序能夠?qū)崿F(xiàn)。但如果異庫、異構(gòu)、同步，那將是極其耗費工時，并且麻煩的工作。
（2）如果相對數(shù)據(jù)庫進(jìn)行優(yōu)化，可為系統(tǒng)制造第二期計劃；
（3）抱著不想看舊系統(tǒng)業(yè)務(wù)邏輯代碼的想法都是過于理想、不現(xiàn)實的。這個項目我是前期的后半段加進(jìn)來的，之前的核心開發(fā)人員對甲方的開發(fā)人員說：“我想最壞的情況就是要看你的業(yè)務(wù)邏輯源碼才能實現(xiàn)新系統(tǒng)，這是一份耗時耗力的工作。前期我盡量將你們實際的需求和注意的點都挖掘出來。”前期確實在需求上下了很多功夫，但是真正投入開發(fā)后才知道，了解程度遠(yuǎn)遠(yuǎn)不夠，很多之前的存儲過程因為年久未作修改，當(dāng)時了解時甲方的開發(fā)人員都說得有異議。最后在項目后期還是落得去核對甲方的存儲過程來確認(rèn)是否自己的開發(fā)過程有細(xì)節(jié)遺漏。
（4）不要幼稚到將一個已經(jīng)運(yùn)行了近6年、一直在增加和修改需求、并且在中國各地都分布運(yùn)行、甲方若干能力還不錯的開發(fā)人員維護(hù)的系統(tǒng)想象得過于簡單。若干的地區(qū)個性化需求（有的需求甚至一點都不合理）、長久積累的靈活性功能等等，會讓你相信“沒那么簡單”。
縱觀這兩個項目，為何做得如此步履維艱？是否做過類似項目的你也有過這樣苦不堪言的體會？筆者所做過的其余多個全新系統(tǒng)，好像還沒遇到過開發(fā)得如此艱難險阻的。希望看到此文的技術(shù)同仁們，萬一不得已遇到類似的項目，千萬不要想得過于簡單吧！重視它，是成功的第一步！