提升開發的品質，從管理原始碼做起

程式人工作的主要產物，無疑就是程式的原始碼。開發的心力持續一段期間，過程中，不僅創造出新的程式碼，同時還有可能修改既有的程式碼。於是，程式原始碼需要妥善管理。

對於那些尚未施行版本控制系統的開發團隊，我想說的是「控制開發的品質，就從控制原始碼開始」。

單兵作戰不能忽略備份和版本對應的工作
單兵作業的獨行俠，所有的程式碼是由一人獨自開發，而且只儲存在自己的硬碟中。有時會有偶發的災難，例如硬碟損毀了，於是所有的心血全部付諸流水。

而且，如果程式人儲存在硬碟中的原始碼只有一份──最新版本那份，那麼如果之前曾經釋出過各種版本，而這些流落在外的程式出問題，需要修正時，沒有時光回溯機的程式人，無法倒轉時空到指定的程式版本修正。

有著良好習慣的程式人，或許會定期備份，因此當原始碼損毀時，有機會可以絕處逢生。而且，在每次程式發行時，程式人都留下和該版本的所有原始碼，以便在任一發行版本需要修改時，找到相對應的一整套原始碼。而這備份及版本對應的動作，已經算是基礎的原始碼管理。

群體開發模式，需留意程式合併與版本衝突的調解問題
當開發進入群體的開發模式時，單是備份以及滿足版本對應的需求，也不足以克服更進一步衍生的問題——原始碼的版本因為參與者不只一人，而變得更為零亂且分散。

許多人同時參與同一開發專案時，可能同一時間會有不只一個人握有整個專案的原始碼，而且同時間也不只一人修改某個原始碼檔案。不論他們彼此之間是否知道，可能有其他成員也在修改同一個檔案，當他們各自完成原始碼的修改之後，理論上，每個人的修改都應該生效。

這些修改的內容或許互不相重疊，但程式人們要如何將這些合併在一塊呢？倘若這些內容重疊，也就是說，程式人們的修改發生了衝突，那麼調解衝突時，究竟要以那位程式人的版本為依據呢？

更危險的是，當某程式人根本沒有查覺或意識到，發生了需要合併或調解衝突的情況，整個專案不是出現了多份在團隊中同時流傳的原始碼版本，就是發生後者覆蓋前者，導致前者的內容完全消失的慘劇。

多人開發模式下的原始碼管理問題
我們不難在身邊發現，多人開發模式常發生類似以下的例子。

一、使用電子郵件交換自己所寫下、修改的程式碼：每個人手上都可能還有一份相同或不相同的原始碼檔案，沒有人知道究竟誰發出來的程式碼，才是專案中正牌的那一份。也不知道這次所收到的原始碼，和手上的那一份究竟有什麼樣差異。

二、使用FTP或網路芳鄰之類的網路檔案伺服器，集中擺放所有原始碼：這麼一來，伺服器上的原始碼，就是專案中唯一的正牌。但是，當同時間不只一個人修改相同檔案時，系統未處理修改內容的合併或衝突調解，所造成的悲劇，就會一而再、再而三地上演。

三、權限不分：關鍵重要的程式碼，可能被未經授權的程式人取得甚至流出，或者不小心做了錯誤的修改。

四、缺乏修改歷程記錄：不知道某一個發行版本與下一個發行版本之間，原始碼究竟修改了哪些，以及為什麼要修改。你不知道某個臭蟲究竟是在那一個版本中修正的，或者即使知道是在那一個版本修正，也不知道是修改了哪些，而除去臭蟲。

原始碼的管理，必須解決多人存取衍生的差異與衝突
上述所提到的個人開發模式及群體開發模式下對原始碼的處理情境，正好點出了我們對於原始碼管理的需求。

一、 要能保障程式碼的安全、不致於因為個人電腦的損毀，而造成程式碼永久消失。

二、 要能重製任一發行的版本，並給定任一個發行的版本號碼，使得未來能取得該版本所對應的整個專案原始碼。

三、 要能偵測出多人開發時的合併及衝突，並盡可能地自動處理，及建議調解衝突的方式。

四、 要能控管不同成員的存取權限。

五、 要能記錄及查閱修改歷程的記錄，以便調出程式碼在不同版本之間的所有差異，以及發生差異的原因。

所謂的「原始碼版本控制系統」便是要解決上述問題的工具。一些常見的系統，像是CVS、Subversion，或是Visual SourceSafe等，都已經在業界廣泛地運用。透過這些工具，你可以將專案的原始碼，放置到一個集中的儲存空間，而當你完成了修改某一個檔案的動作之後，可以將它送回這個儲存空間，並且記錄這次修改的動機及結果。

版本控制系統也會自動記錄此一修改版本與前一版本間的差異。版本控制系統或許會防止多人同時修改同一檔案，以便控管同時間僅有一人修改。它也可能允許多人同時修改同一檔案，但當多人依序送回修改內容時，系統能自動偵測出需要合併或調解衝突，進而自動合併，或提示程式人必須調解衝突，從多份檔案中決定一個最終的結果。

版本控制系統也允許程式人加註標示，以利調出任何一份你所需的整個專案原始碼，進一步重製任一發行版本。當然，典型的版本控制系統，也能依據權限決定不同參與者的檔案讀寫權限。而像支援分支（branching）這樣的機制，也是現代版本控制系統的必備要素。

體認版本控管系統的重要性，才能避免災難
不使用版本控制系統的多人開發，很明顯地十分容易發生災難。但為什麼開發團隊仍舊不願意使用呢？我認為原因多半出在：不願意學習新的工具，以及不願意「浪費時間」在這些額外的動作。

這兩項不願意，是因為程式人沒有確實體認，缺乏版本控制系統所造成的傷害。相當諷刺的是，程式人浪費時間及心力，在不斷地遺失自己所做的程式修改之後，努力回復程式應用的面貌，卻不願意利用些許舉手之勞，協助自己規避這些麻煩。

專案經理有責任讓版本控管成為開發生活的一部分
身為領導者的你，如果團隊沒有施行版本控制系統，那麼你應該擔負起大多數的推動責任。你該做的事包括：

一、 讓每個人都明確地明白、並體認版本控制系統所帶來的好處。

二、 給予充分的教育訓練，讓每個人都能自在地運用基本的版本控制機制。

三、 讓版本控制系統像空氣和水一樣，成為開發生活的一部分。

第三點格外重要，因為這意謂你必須建立起團隊文化，讓每個人習慣而且一定要使用版本控制系統。例如，讓每個成員在一天開始工作之前，習慣去做的第一件事，便是自版本控制系統中更新原始碼。在每次完成一個小的段落，讓程式碼達到可正確編譯、可測試的標準時，便立即將所做的修改送回版本控制系統中。

當你成功地透過宣導版本控制系統的好處，進而建立起常規運行的團隊文化時，成員們將會更深刻地體認到好處，因而更正面地將這樣的習慣，當做是空氣和水一般稀鬆平常，但又不可或缺。

當這樣的習慣發展成為「少了版本控制系統的輔助，便覺得開發工作難以進行」時，就是成功之日了。

作者簡介：
王建興
清華大學資訊工程系的博士研究生，研究興趣包括電腦網路、點對點網路、分散式網路管理、以及行動式代理人，專長則是Internet應用系統的開發。曾參與過的開發專案性質十分廣泛而且不同，從ERP、PC Game到P2P網路電話都在他的涉獵範圍之內。