大學裡面的幾個失敗專案

今天想起大學時參與的一個專案，讓我突然想起了一些事情，多年之後再來看原來的我，發現其實還是有不少的建議。
那時候是暑假的時間，課程裡面專門安排了一個專案實踐，因為也沒有實際的專案可做，所以也就是根據老師提供的素材來自己選擇一個專案，給了三個專案，每個小組是10多個人，當時學軟體工程也有些日子了，論逼格的一句話，當時的軟體工程教材還是全英文的。當時大家實際參與到專案中的時候，也都是一頭霧水，不知道該從哪裡開始。
    記得給的時間也不長，大概一個專案週期下來就是2周，然後就要開始小組演示。所以從一開始就註定了這是一個簡單的專案實戰，因為大家都沒有頭緒，誰都沒有敢想到兩週後的那天到底會是什麼樣的場景。
    於是乎，大家就在教室裡隨機分組，然後評選專案經理，挑選專案，然後就是挽著袖子開始幹活。
    沒有思路，但是我們有模板，所以從這個模板中也可以看到一些工作的分工和任務，當然老師也會在整個過程中穿插指導。如此一看一切都準備妥當了。

在專案開始的時候，充分感受到了民主的風氣。小組先分工，有做概要設計的，詳細設計，資料庫設計，測試的分工，對於測試的部分大家都不大願意幹，所以最後的情況就是自己開發自己測試，在專案開始的時候，大家感覺詳細設計才能敲一下程式碼，才覺得自己實際上幹了些活兒，雖然從軟體工程中的學習我們知道概要設計是一個非常關鍵的環節，但是到了後面基本就是一個蘿蔔一個坑，你做你的概要設計，我做我的詳細設計。
    我和另外一個女同學被分在了一個小組，負責概要設計，後面人手貌似不夠，我們也負責了兩個模組的詳細設計。今天在郵箱中翻找，也算找到了當初的一點設計的東西，其實我們最開始在梳理關係的時候，也著實花了不少的功夫，也是通過rational rose來設計uml圖，至於後來的結果怎麼樣，其實也是不得而知。因為設計和實現還是有很大的差距，至少當時是脫節的。

至於到底關係如何細粒度，到底是泛化還是其它已經不重要了。當時分工也看起來有模有樣，分出了兩個人做DBA，專門負責設計表和索引，說實話當時還是挺羨慕的，因為感覺建好表他們就沒什麼事情了。
    我們三個組，從我們的整體感覺來說，風格迥異，第一個組裡似乎多了很多的程式設計師，因為大家都希望其他人能夠複用他們寫的程式碼，所以在開始的模組分工和功能劃分上，下的功夫不夠，於是乎，幾波人都要做一個登陸驗證的工作，然後各自開發自己的功能模組，當時他們的進度一度超過我們。
    我們是第二梯隊，算是裡面的溫和派，大家在專案裡似乎沒有那麼多的爭執，在分工上有一點做的比較好的是，我們制定了一個統一的配置檔案，按照模組劃分，所有的主類都需要在這個配置檔案中定義，然後劃分每個人負責的功能模組，所以幾個模組之間可以看做是獨立來操作的，當然缺點也很明顯，後面單撿出來說。第三個小組下的功夫最大，總能看到他們在那加班加點，他們也會有爭吵，但是也會在專案經理的調和下馬上平息，設計上也著實做了點東西，他們是嚴格按照MVC的設計方式實踐的，其中為了突出DB層面的獨立，硬是搬著電腦扛到教室，然後通過校園網連線到宿舍裡的DB伺服器,他們就想說明他們的DB是分離的，絕對不是本地的連線方式。
    很快就到了專案驗收的階段，三個小組都在最後的時刻開始了整合，整合，結果馬上就暴露出來了一系列的問題，第一個小組因為大家開發的東西耦合度太高，最後整合程式碼以後連登入頁面都打不開，然後各個小組都不願意再做很大的改動，所以整合就是個大問題。當然如果要做進一步的整合，有些人的功能程式碼肯定是要直接拋棄了，所以他們在後期的時候最為艱難。
而我們小組在這方面確實是佔了大便宜，我們整合的時候就是提交配置檔案的主類，專案經理把這些配置整合到一起，然後程式碼都放在各個目錄下，直接拷貝就能各盡其用，所以整合基本上沒有花費什麼時間，但是問題也很明顯，我們每個人只負責自己的那個模組，其實很多模組之間還是有很多的關聯，所以我們看起來功能實現了，但是完全解耦合，模組之間彼此沒有任何的關聯，也是前期的溝通和分工不合理導致的情況。如果再進一步來說，我們的這個系統只能查，完全不能用。第三個小組亮相的時候，也著實讓我們刮目相看，他們實現了部分的功能，按照當時的分工和計劃，他們完成了很少的一部分功能，演示的時候也顯然弱化了這方面的缺點，因為大家都不關心裡面的功能是否設計合理，只要能開啟頁面就感覺是一個基本的交代了。
    在下午之後，大家的分數基本持平，每個人都感覺像經歷了一場戰爭，終於可以放鬆就好好喝喝酒，玩樂玩樂了。
    雖然老師也從優缺點的方面做了總結，但是現在來看，三個都是失敗的半吊子專案，第一，專案的立足點就沒有任何的需求，都是按照模板來完成，而且當時評判的一個標準就是頁面是否能夠顯示出來，這一點現在想想簡直是不敢想象。第二這個專案的分工大家都在選擇迴避，還是逃避了不少的潛在問題，在分工和溝通上還是不合理。第三這個專案就是個臨時工程，大家寫完的程式碼絕對不想再去看第二遍。
    當然在大學期間，我們不能要求太高，說得那麼輕巧，落地實踐不了還是白瞎。我們在後來也自發組織了幾個同學準備也做個專案試試，在商量再三，決定做宿舍管理系統，有了上次的經驗，我們這次的合作相對就會合理很多，但是最後也因為專案沒有太多明細的計劃最後一再擱淺。
    所以這些專案雖然看起來都是失敗的，但是也著實給了我不少的寶貴經驗，再到後來，做畢業設計的時候，大多數的同學都還是按照之前的專案的思路來做，其實專案怎麼樣，關鍵是論文的質量了，所以大家都在關注論文裡面的引言，內容，然後找幾張圖片來嵌在文件中，這也算最後一個實戰專案了，所以我想讓自己做得能夠有點談資，於是乎我挑戰了一個專案，電信效能監控系統，從當時的完成情況來看，完成了差不多50%的功能，而後來得知這個專案是哈工大的研究生專案，一個小組10多個人幾個星期才能完成，所以也著實讓我小小滿足了一把。
   回過頭來看看以前的日子，感覺時間真是一去不復返，那些當時看起來非常艱鉅的任務現在來看是有落差，但是其中經歷的一些事情也是難得的經驗，從這些也可以一窺很多經驗錄，方法論。其實大學就是這樣一個可以埋頭做事情的大好時間，如果珍惜了，做好了，肯定會有不小的收穫。
 

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/23718752/viewspace-2093094/，如需轉載，請註明出處，否則將追究法律責任。