輕鬆談軟工

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

版本控管 在整合國科會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)，在文件部分，要進行編輯的文件一定要