發表文章

目前顯示的是 12月, 2009的文章

無題

趁歲末,我花了一點時間,回憶一些各方對今年發表的諺語與部落格文章所提出的意見,雖然這些意見不能涵蓋全面,但多少反應一些現象,這種現象顯示國內軟工教育問題,就是學校的軟工教育訓練不能完全『 學以致用 』,也讓我這個開授軟工課程多年的教師匠有點『做白工』的感覺,嚴重一點說,有點誤人子弟。 話說,從今年2月20日薛教授post上去的『好人難為』一篇文章,以及最近Q39諺語:『Schedule是用來Delay的』說起,我覺得我們的軟體工程師似乎受很大的委曲,大部分的委曲都是說很難與老闆溝通,有人說溝通無效只好忍氣吞聲,或者默認,甚至乾脆打包走人(「好人難為」意見箱),『‧‧‧要不然抱怨變化永遠趕不上客戶的一通電話』(Q39諺語),甚至說如果客戶來個需求變更,那(專案)就要delay到天荒地老等等,是不是那麼嚴重,我想還不至於吧,不過我相信這些抱屈都是事實,也都是經驗之談,不過從軟工的角度來看,似乎並不希奇,雖然有幾位教授以及本人對這種現象多少有些解釋也提供一點意見,我相信這種現象並非完全無解,重點在於『學以致用』,要致用當然要『百鍊成鋼』,只可惜據我所知,許多學校的軟工訓練並未提供這種機會(包括我自己),例如世界上許多軟工界的『先賢』或『現賢』,提供不少設計軟體的方法(methodologies)、原則(principles)、或樣式(patterns),諸如Agile Methods,Protected Variations及其引伸的OCP、DIP、或Information Hinding等等原則,我不知我們的軟體工程師發展軟體時是否應用到這些『優美』的方法、原則、與樣式?但這些設計原則的確可以解決上述不少問題,我不相信當我們的工程師要應用這些方法‧‧‧時老闆會加以干涉,如果我們的軟體工程界發生這種干涉現象,『軟體工程學會』應該出面解釋甚至說服,學會有責任導正軟體發展的方向,而不是只開開會討論了事,這是我寫這篇不怎麼討喜的短文主要動機。

軟體工程與大型整合專案—以WiMAX整合型計畫為例 (2/3)

圖片
版本控管 在整合國科會CMMI文件與程式開發的過程中,總計劃與各子計畫的文件與程式都需要一個版本管理的機制,一方面萬一有電腦當機或是檔案損毀時,可以迅速還原最新的版本,解決資料備份的問題,另一方面還可以在歷史紀錄中往返,將刪去的文件或程式找回來。對於文件或程式整合而言,版本控管十足是一個Time Machine。 我們在第一年開發之前就已經預期到版本控管的重要性,因此在專案初期便架設可透過Web介面存取的版本控管伺服器(Apache + Subversion),並且安排Subversion的教育訓練。但是,可能是一開始時教育訓練的內容安排不符合需求,也可能是開發團隊不夠用心,導致版本控管並不上軌道。最常發生的問題包括:團隊成員未確實解決衝突(Conflicts)、久久不送交(Commit)程式、送交無法編譯的程式、送交時不寫註解等。 這些問題的原因,有部分與先前討論過的缺乏一致的開發環境有關,部分團隊使用的IDE沒有支援版本控管,所以得在IDE編譯完後才知道有沒有問題,然後再使用其他版本控管軟體(TortoiseSVN等)送交程式;或在Windows上取出(Check out)程式然後複製到Linux的機器上修改與編譯,然後再複製回Windows上覆蓋舊版本後送交,然而在取出後到送交前的這段時間,如果沒有進行更新(Update)和合併(Merge)的動作,這些行為常常會導致衝突。 久而久之,有些團隊成員開始害怕使用版本控管系統,導致送交的週期越來越長,甚至有超過二個禮拜沒有送交程式碼,失去使用版本控管的優點。長時間的修改送交週期,也讓成員忘記曾經修改過什麼東西,自然不知道要寫什麼註解,這些都是讓版本控管失去威力的錯誤行為。經過一整年的觀察後,總計畫在第二年開始前,重新規劃Subversion的使用方式。 首先,我們將版本控管的支援加入一致的開發環境中。在Virtual Machine中,我們使用Eclipse搭配Subclipse套件,讓IDE與版本控管合而為一,之前也提到,單元測試的執行也加到程式中,這些都是確保程式無誤的前置作業。另外,針對文件撰寫的環境(通常是Windows平台),撰寫TortoiseSVN的操作手冊,讓新加入的成員快速進入狀況。 接著,我們訂定幾個需要遵守的原則(Principle),在文件部分,要進行編輯的文件一定要