一次二次開發中的經驗與教訓(一)

       2011年10月份左右，客戶公司（國內較有名的工程機械公司，以XD來代替）打過來電話說要做一個簡訊系統,並且這個系統要嵌入到他們現有的系統中。要實現的功能有以下幾方面：
       一，使用者可以用手機實時查詢機械資訊。並且機械有報警時，可以自動向關聯的手機號碼傳送報警資訊。
       二，系統可以設定，每天每週或每月設定固定時間。來向使用者報告機械資訊。
       三，逢年過節，向使用者傳送一些祝福簡訊。
       這個系統是建立在現有的系統(一個工程機械管理網站，BS架構)之上的，除了資料庫的結構有些交差及使用者登入資訊需要共享外，基本沒有什麼交叉。也算是一次二次開發吧。
       從書面上來看，需求很簡單，沒什麼技術難點，需要注意的地方有以下兩點：
一，使用者的併發查詢處理問題，使用者的數量雖然不算大，但保守也有幾十萬左右（包括XD,XD的職工，XD的機械代理商及代理商的工作人員，還有最張購買的機械使用者）
二，需要分析系統的資料庫及系統程式碼
       這樣我估計一兩個人大約半個月的時間就可以完成，再過半個月部署（需要出差，來回要兩天的時間,再加上測試，除錯的時間），這樣基本1個月綽綽有餘。而且我也將需求說明書及系統概要設計寄給使用者，他們也簽了字的。於是在合同簽署後我們就開始進行開發了。
專案組算上我一共4人（其中一個以前是做windows phone 開發的，稱為C），根據需求，我將系統分為了三個程式或者說模組，一個是XD與XD的使用者檢視資訊用的簡訊系統(B/S),我讓A負責使用者的日常資訊處理，B負責使用者的報警資訊的查詢。這個系統需要嵌入到現有的系統中，一個簡訊監控程式，負責實時的處理使用者的請求，及資訊的傳送(一天的資料處理量約有10000左右，而且根據使用者要求必須在10分鐘內將10000條簡訊傳送出去，而且要處理第一次傳送失敗的重發。拋開簡訊硬體的功能不說，軟體要在10分鐘內處理完成，也不是非常容易的，所以這個模組我來寫程式碼)。考慮到人員的充分利用，我讓剩下的C開發功能比較簡單的其它附加功能。分好各人的工作之後，我就按照XD提供的資料開始進行分析，真是不看不知道，一看嚇一跳，別的不說，就拿資料庫來說，連個基本的資料庫設計文件也沒有(這也是國內大部分公司普遍 的通病)，而且命名也不一致。導致我前期的資料庫分析與設計延遲了好幾天。
       而且還有一個比較嚴重的問題是，資料庫裡各種型號的報警資訊是不一樣的。不止是欄位名不一樣而已，而是報警的欄位意義也不一樣。有的是0表示正常，1表示異常的。有的則正好反過來。有的則用true/false來表示。而且，同一個型號的機械它們的字首也不一樣。這樣給我前期的設計帶來了許多意想不到的困難。
  不管怎樣，資料庫分析好後，我們就開始進入編碼階段，基本上一個星期左右，編碼完成。我們先在我們的伺服器上進行測試，因為要模組客戶的實際環境，我就把XD的資料庫Schema拷貝過來，在我們的伺服器上新增了約有幾十萬條資料，然後開始測試，基本上一兩天測試完成（我基本上屬於那種小心謹慎的人，晚上還熬了個通宵來檢視程式執行的穩定性,這個領導都不知道，我也不願意說出來因為屬於本職工作範疇內）。但在給客戶看後，它們說要把介面改成跟原先的系統一致的（這是我的工作失誤，淨考慮系統的功能，認為只有幾個頁面，做的簡潔大方就可以了，所以就沒有跟使用者溝通頁面的效果）,不過，俺各類語言都不敢說精通那也是熟悉，js/css不在話下，三下五除二，哦不，是半天時間，將頁面修改完畢。
         給客戶看後，基本沒什麼問題。然後我就到常州開始部署系統。原以為沒什麼問題了，然而這才是麻煩的開始。 
          到常州後，我沒有休息就趕到XD公司，與客戶代表做了簡單的交流後，他又提出了一些新的想法，而這些想法是在原先的需求里根本沒有的,但考慮到XD是我們目前最大的客戶，我忍了，按照他們的需求，對系統做出了改動，而悲催的是XD公司為了安全起見，斷了外網，公司職工只能上內網及指定的外網，而且除了80外，別的埠都封掉了，於是我只能通過他們的伺服器上的qq給遠在千里外的同事傳送使用者的需求。