輕鬆談軟工

Continuous Integration 在討論版本控管時，我們曾經提到WiMAX計畫使用一個輔助工具「 JCIS 」進行持續整合(Continuous Integration)的工作。那麼，為什麼要做持續整合呢？維基百科中對於 持續整合 的理論有些初步的介紹，包含下列十個重要的Practices： 維護一個程式庫(Maintain a code repository) 將建置自動化 (Automate the build) 使建置能進行自我測試(Make the build self-testing) 每人每天送交程式碼(Everyone commits every day) 每次送交都應該被建置(Every commit should be built) 維持快速的建置時間(Keep the build fast) 在實際運行的環境下進行測試(Test in a clone of the production environment) 簡化取得最新可交付版本的方法(Make it easy to get the latest deliverables) 每個人都能看到最新版建置的測試結果(Everyone can see the results of the latest build) 將佈署自動化 (Automate deployment) 上述許多Practices都要求自動化，自動化又可以分為半自動和全自動，以半自動為例，可能是有人每天固定手動執行make指令，將所有要建置的檔案編譯與連結，接著有人將結果複製到實際運行的環境，再下指令讓電腦執行所有的測試，這個過程雖然必須由人來操作，但只要下少許指令就可以完成了。那麼全自動呢？就是在專案開始的時候進行若干設定，之後由電腦自動處理一切編譯、連結、測試等工作，這就需要一套輔助工具了。 要確實完成這麼多的Practices，其實門檻是很高的。即使是在企業界，也難免會有不遵守遊戲規則的軟體工程師，更何況我們的開發主力是學校裡沒什麼專案成敗壓力的學生。舉例說，要做到「每人每天送交程式碼」幾乎是不可能的，基本上學生開發程式是有一天沒一天的，最多只能要求到「有修改就必須送交程式碼」。另外像是「每次送交都應該被建置」，在我們第一年的WiMAX計畫中可以說是完全失敗。在開發環境未能統一的...

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

以往學生在學軟體工程時，總覺得這門課就是在「寫文件」，對於為什麼要寫文件，以及文件的用途，不甚了解，甚至覺得寫文件是很枯燥乏味的一件事。的確，為了交作業而寫文件，我想沒有人會認為寫文件是有用的，特別是對於一個虛擬的軟體專案而言，即使必須開發對應的軟體，充其量也是一個小品，而且一個學期的時間又很有限，所以不是文件品質不好就是軟體沒寫好，更別提要維護了， 而學生無法對軟體跟專案產生情感，自然無法體會文件的意義。 過去三年，筆者因為主持國科會整合型計畫「WiMAX 無線通訊系統軟體與工具開發(I),(II),(III)」的關係，需要主導撰寫其Light-weight CMMI文件，剛開始的第一年，參與計畫的學生們也是哀鴻遍野，學生們即便已經參加過國科會舉辦的Light-weighted CMMI研討會，寫出來的文件，和實際的軟體設計仍有一段很大的落差，一直到第二年，需要開始維護第一年的軟體時，學生才慢慢體會到軟體工程要的不只是文件，而是文件所帶來的價值：溝通與管理。 有一個經常被提到的問題是「軟體流程」？我們的WiMAX整合行計畫到底有多大呢？是否真的需要軟體工程或是完善的軟體流程才能完成呢？這裡先簡單描述一下我們的案子，大家都知道WiMAX被視為M-Taiwan重點發展項目，WiMAX(802.16e)是一個相當複雜的通訊協定，而我們的目標是開發一套完整的「WiMAX網路模擬軟體」，由於WiMAX由上到下包含許多子層，而各子層又各須非常專業的知識，因此，這個案子需要軟體工程加入，才能有效地整合各種跨領域的知識，構成一個完整的系統。也因此我們(北科大軟體研發中心)才提出這個跨領域的整合型計畫，希望開發出WiMAX網路模擬軟體，以開放原始碼的方式貢獻給業界作為WiMAX參考模型，並分享我們的開發經驗。 在WiMAX的案子中分成三個主要項目：「應用」、「協定」與「輔助工具」，應用有「即時視訊傳輸應用」與「適地性資訊服務」；協定負責WiMAX通訊協定的所有子層包含媒體存取控制、安全加密、實體層編碼、實體層調變與通道模擬；輔助工具則提供通訊軟體模型建構工具與持續整合等輔助。由此可知，計畫規模頗大，最多曾經有12個子計畫。軟體流程不能保證專案如期完工，但能用來監控時程與進度，如果沒有流程，進度落後或是超前，都無法掌握，那軟體勢必是無法順利開發與整合的。 有了第一年的...

我自己以前很喜歡寫程式，現在不年輕了就較懶惰，所以大家猜的出來這故事發生在很久很久以前... 一顆1MB的RAM要一千塊美金，而且要排隊一個月才買得到的時代 。 我當初為了一家forwarder/broker（海陸運）公司寫一些應用程式。幫他們架網路，再完成了會計系統、出入口系統等業務的東西，終於要幫Sales的人們開發他們的系統。花了一些時間，把基本需求完成，然後很雞婆的幫他們作了一個小工具。結果，那個小工具成為Sales的人們最喜歡用的功能。 為什麼說雞婆呢？因為這沒有在他們本來的需求裡，而是在某幾次吃飯或咖啡場合聊他們做事的方法，我自己去作一些prototype開發出來的。其實那個功能需要跨幾個資料庫撈一些資料再整合，只是我們當初所使用的資料庫系統會鎖住資料庫，沒辦法邊看邊編輯資料。其實是為了安全的考量，資料庫鎖住是很合理的事。可是為了這限制，我一直沒有辦法完成我想要的功能。最後，在某一次的嘗試中，動態跑到作業系統裡把lock挪掉，做完工作，再把lock搬回，竟然就完成了所期待的工作。雖然有些危險，但是我非常有把握在這些功能的使用範圍內，應該是不會發生任何問題。 事實上，這工具他們之後用了很久，而且沒有發生任何意外。直到有一天我接到越洋電話... 時間已過幾年，我也搬來台灣。原來他們要upgrade系統，再重建構系統，所以希望我說明當初到底用了什麼撇步完成那功能。 坦白說，我連什麼功能都忘了，哪裡記得什麼妙法？ 不知道各位有類似的經驗嗎？很多時候拼命coding，不是trial-and-error，就是靠著一些靈感完成工作。然後，沒記下來，過幾天就忘光光了。 明明知道要加註解，可是怎麼可以停下這麼順的『手感』，就繼續code下去了。更不用講到文件了...

這是一個專班學生的故事。 他的工作是跟物料管理系統的開發相關。公司用的實作框架中包含一個 tree 的 model。有一天，因為使用者的需求變更，他的上司決定把 tree  model 改掉以快速的解決顧客的問題。他仔細的看了這個方法，知道一定會對後續的成本計算產生問題，因此請主管不要改 tree model。 但是顧客的問題必須要馬上的被解決，所以主管決定還是要改。有軟體工程概念的他，瞭解這個問題的嚴重性，他深深的知道這個東西一改，以後的程式都會以這個基礎下去開發，到最後成本計算穩死無疑，因此堅決不可以改，兩個人於是吵了起來。 其他的組員覺得他很奇怪，沒事為什麼要跟主管過不去，還跟主管吵架。在一個保守的組織中，他的『雞婆』並沒有受到肯定，也沒有人有時間深入瞭解他所說的道理，只是覺得他很『機車』，他只好閉上嘴巴照做。 過了三個月，這個問題浮現了，大家忙得雞飛狗跳。但是，沒有人知道他們所遇到的問題是主管所造成的，也沒有人想到他。大家忙著找一個可以立即解決成本計算錯誤的方法。也許，再把 tree model 亂改一通吧。 大家覺得這個故事有哪些啟示呢？

已經是好久以前的事了… 我們到一個部門跟他們談office automation，問他們需要什麼。他們竟然很訝異的說『電腦不是什麼都會嗎？』（雖然過了好多年，這好像仍然是一些人會問的問題） 拿出我們軟工的本領，就開始『需求工程』了，可是問題不太像我以前所碰到的CASE容易，更不像課本裡所說的那麼單純。我們問他們如何作業，沒有人講得清楚，甚至有許多不同版本。結果變成我們替他們釐清問題，替他們定義一些作業方式，就像我們替他們定一堆SOP一樣，結果還被批評一番。經果許多討論與翻修，終於完成。這中間有多少時候我常想，為什麼不是他們，而是我在替他們定需求呢？難道我以前碰過得人，就那麼的合作嗎？ 好不容易prototype出來了，他們開始使用好像不太熟悉，可是試用一段時間後，他們終於瞭解原來電腦不是什麼都會，可是同時看到他們可以藉著軟體系統作更多的事。 以後幾年的合作，他們從被動不合作的『使用者』，變成主動且很聰明的『需求提供者』。他們的胃口也變大，可以想出一大堆非常有創意的應用。真的很難想像當初那不太甘願合作的樣子。 不知大家有沒有，相似的經驗？假如以為需求分析，只是問問東西，或是定一些定義出來，那就好像不是這麼一回事了。

這是我還在讀研究所時所發生的事。有一個在職的同學突然間常常出現在實驗室，一副很輕鬆的樣子。他的公司在美國算是很大的公司（應該說是非常大的公司），軟體部門也非常大，而且他一向忙得不可開交，很難想像他怎麼有可能這麼輕鬆。原來他們所做的project 竟然提早一個月結束，team leader告訴他們不要讓經理知道他們已經做完，暫時享受一下悠閒的時間，所以他就有時間來學校晃一晃。 這種事當然不可能常發生，可是到底發生什麼？是招標端（客戶端）的評估能力差？cost estimation 的問題？project planning的問題？太高估了？假如兩方老闆發現了，會怎麼樣想？假如你是team leader你會作什麼？more testing? more refactoring?