文：阿蜜果

日期：2011-10-21

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

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

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

（1）二手項目：都是5、6年前開發完成的項目，新系統的目標是用新平臺實現舊平臺相同的功能。

（2）開發文檔不全：第一個項目之前是C/S結構，使用dephi編寫，只有一份代碼眾多的dephi編寫的源代碼，涉及到業務邏輯的部分都封裝在tuxedo中，數據庫不用改造，數據庫操作邏輯部分依然調用之前的tuxedo業務。第二個項目使用甲方的呼叫平臺編寫，該平臺功能不夠強大，在所有涉及到數據庫操作的部分都調用由其開發人員編寫的SQL Server存儲過程，可以拿到甲方的文檔有：數據庫說明文檔、存儲過程源碼、呼叫流程（發現已經有一段時間沒有同步更新）、簡易的需求文檔。

（3）需求不明確：第一個項目沒有明確的說明文檔，為數不多的知道這個項目的人也只能說個五五六六，需要通過他們安裝好的C/S系統來了解，甚至要通過源碼來了解。第二個項目有簡易的需求文檔，但年久未更新，而上線的系統卻一直在更新，只能提供不夠完全的參考。

（4）之前開發人員的流動：第一個項目之前的甲方開發人員都已經走得七七八八，剩下的1、2個知道點情況的人也已經是從前任的前任手里接過來的項目，現在沒有正在運行的舊系統。第二個項目雖然情況好點，但知道項目總體情況的人也寥寥無幾，但是現網在全國80來個點都有舊系統在運行。

（5）都需要變更平臺：第一個項目數據庫結構不需要變更，但平臺需要變更，由dephi->Java，我們項目組無人學習過dephi。第二個項目之前采用甲方的呼叫開發平臺 + SQL Server存儲過程，新系統采用我方的呼叫開發平臺，該項目甲方還需要變更數據庫，從SQL Server變更為Oracle，并且有很長一段時間兩套系統要并行，因此不但涉及到要割接數據，還涉及到兩邊數據庫的雙向同步。

 第一個項目從頭到尾都做得苦不堪言：工期緊張（貌似是2個月還是3個月）、項目組成員有幾個是新員工、dephi的代碼被甲方的開發人員寫得晦澀難懂，周旋于一個源文件4000、5000行的dephi代碼當中，而且甲方要求甚多，又不能提供良好的支持，項目組成員被摧殘得“花容”失色，而且經過日復一日的加班加點讓項目組成員流失慘重，經過延期、延期再延期，最后不出所料的以失敗收場。

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

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

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

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

（2）如果相對數據庫進行優化，可為系統制造第二期計劃；

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

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

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