文：阿蜜果

日期：2011-10-21

版權所有，轉載請注明出處

在六年半的開發(fā)和管理歷程中，曾經(jīng)做過這樣的兩個項目，都是步履維艱、越做越增添無力感的項目，現(xiàn)在回想起這兩個項目，原來有那么多的相似點，而且原來從開始到結束都已經(jīng)處處透露了危險的信息，只是在初期并未察覺，將危險訊號說出來，讓大家能引以為戒。

這兩個項目的共同危險點是：

（1）二手項目：都是5、6年前開發(fā)完成的項目，新系統(tǒng)的目標是用新平臺實現(xiàn)舊平臺相同的功能。

（2）開發(fā)文檔不全：第一個項目之前是C/S結構，使用dephi編寫，只有一份代碼眾多的dephi編寫的源代碼，涉及到業(yè)務邏輯的部分都封裝在tuxedo中，數(shù)據(jù)庫不用改造，數(shù)據(jù)庫操作邏輯部分依然調用之前的tuxedo業(yè)務。第二個項目使用甲方的呼叫平臺編寫，該平臺功能不夠強大，在所有涉及到數(shù)據(jù)庫操作的部分都調用由其開發(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)在沒有正在運行的舊系統(tǒng)。第二個項目雖然情況好點，但知道項目總體情況的人也寥寥無幾，但是現(xiàn)網(wǎng)在全國80來個點都有舊系統(tǒng)在運行。

（5）都需要變更平臺：第一個項目數(shù)據(jù)庫結構不需要變更，但平臺需要變更，由dephi->Java，我們項目組無人學習過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代碼當中，而且甲方要求甚多，又不能提供良好的支持，項目組成員被摧殘得“花容”失色，而且經(jīng)過日復一日的加班加點讓項目組成員流失慘重，經(jīng)過延期、延期再延期，最后不出所料的以失敗收場。

現(xiàn)在如果來總結這個項目，如此多危險信號的項目就不應該簽約，這個項目的如此種種，注定了他是一個鐵定會失敗的項目。甲方開發(fā)人員甚多，有若干Java的開發(fā)人員，卻想交給第三方公司使用 Java來實現(xiàn)，從這里也可以看出這個項目并沒有如甲方前期所說的那樣是個不難應付的項目。可惜我等開發(fā)人員常常沒有做不做這個項目的權利，合同已經(jīng)簽在那里了，只能提供做的過程中的參考意見，sigh……

第二個項目相對要好些，雖然暫時還沒有交付，但是交付的可能性還是很大的，但是現(xiàn)在已經(jīng)延期了2、3月左右，在后期很大一部分開發(fā)工作都放在割接和同步方面，與甲方的存儲過程開發(fā)人員（也是甲方對該系統(tǒng)最了解的人員）J君交流時，我們私下認為：“這個項目最大的失誤在于當時沒采用同樣的數(shù)據(jù)庫結構，而導致給割接、同步和項目開發(fā)造成不必要的麻煩。” 而這個失誤的造成是由于項目前期雙方?jīng)]有人對割接、同步的問題引起重視，而將精力都放在系統(tǒng)的開發(fā)方面，當時由上頭決定了采用新的數(shù)據(jù)庫結構，前期在我方數(shù)據(jù)庫結構出來之前，甲方都沒有提供當前系統(tǒng)的數(shù)據(jù)庫說明文檔。

這個項目越到后期做得越步履維艱，為了避免重犯這樣的錯誤，總結如下，希望涉及到割接、同步、新舊系統(tǒng)并行的朋友開發(fā)時引以為戒：

（1）如果舊系統(tǒng)數(shù)據(jù)庫設計合理，不要動修改數(shù)據(jù)庫結構的念頭，那將是自討苦吃。因為如果是同樣的數(shù)據(jù)庫結構，即使新舊系統(tǒng)采用的是不同的數(shù)據(jù)庫，割接、同步等都可采用數(shù)據(jù)庫方案，即使數(shù)據(jù)庫層面無法實現(xiàn)，也有很多開源的程序能夠實現(xiàn)。但如果異庫、異構、同步，那將是極其耗費工時，并且麻煩的工作。

（2）如果相對數(shù)據(jù)庫進行優(yōu)化，可為系統(tǒng)制造第二期計劃；

（3）抱著不想看舊系統(tǒng)業(yè)務邏輯代碼的想法都是過于理想、不現(xiàn)實的。這個項目我是前期的后半段加進來的，之前的核心開發(fā)人員對甲方的開發(fā)人員說：“我想最壞的情況就是要看你的業(yè)務邏輯源碼才能實現(xiàn)新系統(tǒng)，這是一份耗時耗力的工作。前期我盡量將你們實際的需求和注意的點都挖掘出來。”前期確實在需求上下了很多功夫，但是真正投入開發(fā)后才知道，了解程度遠遠不夠，很多之前的存儲過程因為年久未作修改，當時了解時甲方的開發(fā)人員都說得有異議。最后在項目后期還是落得去核對甲方的存儲過程來確認是否自己的開發(fā)過程有細節(jié)遺漏。

（4）不要幼稚到將一個已經(jīng)運行了近6年、一直在增加和修改需求、并且在中國各地都分布運行、甲方若干能力還不錯的開發(fā)人員維護的系統(tǒng)想象得過于簡單。若干的地區(qū)個性化需求（有的需求甚至一點都不合理）、長久積累的靈活性功能等等，會讓你相信“沒那么簡單”。

縱觀這兩個項目，為何做得如此步履維艱？是否做過類似項目的你也有過這樣苦不堪言的體會？筆者所做過的其余多個全新系統(tǒng)，好像還沒遇到過開發(fā)得如此艱難險阻的。希望看到此文的技術同仁們，萬一不得已遇到類似的項目，千萬不要想得過于簡單吧！重視它，是成功的第一步！