幾個月之前很有幸的參加了該系統的一期結尾和二期工程，先說下項目的背景: 爲東北一國企從傳統人工客服轉向信息化系統的工程。承建給某一知名高校軟件學院，典型的高校工程。這裏並不是說高校工程就是豆腐渣工程，世間萬物都有其兩面性，就看你怎麼利用它。
先來討論一期工程物理架構: 兩臺比較牛X的服務器，一臺做web server 一臺做 database server ， 確實在物理上，這兩臺機器性能無話可說，無論多差的代碼都沒當過機。機器好並不意味着代碼可以亂寫。
再說技術架構，主要用JSF+HIBERNATE+ORACL，不知道爲啥選用JSF，可能那裏的老師喜歡JSF吧，接觸下來相關項目都是採用這個架構，可能高校工程比較偏向於技術工業化？或者這個技術架構能賣好價錢？
最後說下業務架構，一期中主要有基本信息維護(客戶信息，組織機構，產品備件，人員信息等等)，客戶需求單，需求單處理流程及相關派工單生成及處理，自動對工程師進行派工單短信發送，以及在各地平臺中工程師入住情況的短信交互流程。總體上一期的最終交付產品完成了大部分功能。系統上線以後經過一段時間的波動調整後最終成功上線了，成爲該國企一個個性化的集CRM,ERP,協同辦公爲一體的系統。讓該企業在同行業裏信息化流程走到了前列，順利通過驗收。
光輝背後，我們分析下那些陰影的地方。高校項目就意味着參與人員的水平高低不齊，雖然那些都是名校的碩士，在中國實力往往和學歷不成正比，這當然與中國的教育體系有着不可否認的干係。學生就意味着一切都不固定，無法保證全身心的投入在工作上。而軟件系統，我覺得需要時間去沉澱，只有經過參與人員長時間對業務的理解，選擇恰當的技術方案，高質量的代碼，代碼審覈，不斷的重構，才能做成真正意義上的健壯，可擴展的系統。人員的不確定性，導致了寫出來的代碼首先是否能滿足業務需要，其次是否方便以後業務的擴展。這裏往往需要開發人員從業務的角度上去考慮其延展性，提需求的人在第一時間裏往往並不知道他自己需要做什麼。而我們並不能只做他提出的東西，可能第二天他就告訴你，他的注意又改變了。我們不能抱怨需求的改變，畢竟軟件字典裏唯一不變的就是 “需求會改變” 。我們能做的就是擁抱變化。學生一年又一年的更新換代，學生是個很奇怪的人羣，在高校裏很少能有知識分享，就怕別人強過自己。從來不知道“捨得”二字。造成學生換代時，老的恨不的一走了之，新的啥都不懂，剩下老師乾着急。在高校裏學生做項目，就跟小學年代，交作業一樣，能跑就行。在工程裏到處留下過程式的面嚮對象語言，沒有封裝，一長串參數。一個類多的幾萬行代碼。這樣的代碼實在難以琢磨，但又不的不看，無形給後面的接手的人帶來長時間的熟悉期。
最後談談需求方，作爲需求方如果沒有專業的軟件人員，在某些方面就不能太過執着。與開發人員一起從一個折中的角度解決雙方的矛盾。在一期的工程中由於需求的不明確抑或開發人員對需求的不理解，造成系統在數據上的冗餘。從而影響二期工程，後期的工程往往比前期的工程更加困難，前期是從0到1，很簡單，想怎麼做都可以，後期是怎麼讓1變成2變成3，從物理結構上講就要傷筋動骨，所以一個好的系統往往一定要注意前期的設計怎樣考慮到以後的擴展很重要，現在二期的工程統計模塊就是要在一期中錯誤的數據中統計出正確的數據。是不是一件很痛苦的事情。以後還面臨着，數據量增長的壓力，對歷史數據的處理問題。怎樣保證系統數據的完整性和系統的性能，我想那是二期的擴展改進的過程了吧。
想說的太多，可惜自己不是一個善於言表的人，真的希望這個工程能真正的搞好，可惜自己心有餘而環境不足。
最後奉獻一首歌， Nickelback 的 If Everyone Cared 。
