沒有使用版本控制的黑暗時代——版本控制心得（一） (轉)

沒有使用版本控制的黑暗時代——版本控制心得（一） (轉)[@more@]

　　 在沒有使用版本控制的開發團體中，我所熟悉的一種常用開發方式是：多個開發人員共同負責一個的開發，每個人在各自的機器上有整個軟體的複製，並對之實施編碼，分別完成各自任務之後，再透過文字比對工具將各自機器上的不同版本的軟體整合到一臺機器上。

　　 本文就這樣的開發方式，提出在中出現的幾個和版本控制密切相關的典型問題（但未必全面），同樣也是需要透過版本控制來解決的問題，它們來源於實際開發過程中的切身體會，並經過總結和整理。

1 軟體程式碼的一致性

　　 軟體的開發、維護和升級，往往是多個人共同協作的過程。不同人對同一個軟體的不同部分同時做著修改，這種行為有時會出現彼此交叉的情況。由於同一軟體在各自開發人員的機器上都有複製，軟體的全部程式碼都暴露在每個開發人員面前，原則上他有可以不加限制地更改軟體的任何部分。而當他們修改的內容屬於公共部分，或者需要被其他人員所負責的部分時（軟體各模組間的彼此依賴關係決定了這種情況是經常發生的），這種修改就屬於交叉情況。此時，就有可能出現程式碼的不一致現象。比如：修改者在改動了某個公共的同時也修改了其呼叫介面，若其他人員沒有得知此事，而在各自機器上仍呼叫原來版本的函式，則當整合時，就會出現錯誤。另一種更為嚴重的情況是，修改者決定廢棄原有函式而另外編寫一個新的函式，但他並未刪除原有函式，這種情況即使最後的整合也可能不會被察覺，如果將這種一致性錯誤的糾正延遲到測試階段，則會增加的難度，從而降低開發。為了始終保證程式碼的一致性，一種解決辦法是，要求修改者每次修改後都透過某種方式告知同組其他人員，或者隨時對軟體做整合。但是這樣，一方面會增加開發人員的負擔，另一方面也降低了軟體的開發效率。

2 軟體內容的冗餘問題

　　 軟體在各自開發人員的機器上都有複製，並且同一個開發人員在不同時期也會在本機保留當時的軟體版本，也就是說，一臺機器上還可能不止一個版本。這類似於一種資訊的冗餘。對於不同版本而言，其差別有時可能並不很大，如果說不必要的佔用空間是一個次要問題的話，那麼另一個問題可能更重要。隨著時間的推移，開發人員可能對自己機器上的不同版本間具體差異的瞭解變得模糊不情，甚至忘記了當時為什麼區分這些版本的原因，這會給整合帶來麻煩。而且，如果需要同時維護多個版本，則對某個版本的改動可能需要反映到其餘版本的對應處，很難保證這一過程不會出差錯。還有一點，作為開發人員，有時即使知道自己機器上軟體的某個版本可能不會再使用了，他也不會去刪除（生怕萬一需要從那裡獲取點什麼），但是通常也不會再去維護或檢視它，因此久而久之，這種“僵死之物”會在多臺機器上“蔓延”。

3 軟體過程的“事務性”

　　 對於軟體的某個版本，如果開發人員想要為其增添新的功能，或改善原有功能，而又擔心會攪亂原來執行良好的軟體。一種常用的辦法，就是保留現有版本，另複製一個新的複製，並在新的副本上進行修改。這類似於一種事務處理，當將一系列操作做為一個事務時，如果中間某個操作出現偏差，則希望恢復到事務之前的狀況。而當完成修改之後，開發人員該如何處理這兩個副本呢？是在新的副本上繼續新的開發，將之作為最新版本；還是將新的改動加入原有版本，刪除新的副本。無論怎樣，都可能會出現如下情況：如果軟體執行正常，則出現2中提到的冗餘情況；當刪除修改前的版本後，又發現改動中有問題，但已無法恢復了；改動無誤，將改動加入原有版本時，可能出現人為錯誤，導致軟體執行出錯；即使沒有人為錯誤，這種做法也會給開發人員增加額外負擔，一定程度的降低開發效率。重複上述過程則會出現多個類似的副本，此時，如何對待這些不同版本，將是開發人員需要面對的問題。而如果除錯的過程中，發現確實有必要恢復到上一個版本，甚至上上個版本……，此時就不得不保留所有版本了。

4 軟體開發的“併發性”

　　 由於是多人共同開發一個軟體，期間出現多人修改軟體的同一部分，尤其是同時修改，有時是不可避免的。對於前者，具有良好習慣的人員的一種通常做法是，對他人的源進行修改時新增必要的註釋，寫明修改人，修改原因，修改日期等。但實際情況是，當修改內容很零散或修改過程很複雜時，註釋很難寫，或者程式碼被註釋分割得支離破碎影響正常閱讀，或者註釋無法詳細說明實際情況。而且，這種做法也增加了開發人員的負擔：他需要在考慮程式碼邏輯的同時，兼顧如何寫註釋；而對於註釋和程式碼的一致性也是他需要隨時留意的問題，不能疏忽。因此，我認為這種措施在實際開發中，並未取得實質效果，是不必要的，事實上程式碼本身（而非註釋）是最能說明問題的，而修改的記錄應該置於程式碼之外的某處。而且，不論是否是同時修改，都需要考慮1所提到的一致性問題，需要及時進行人工的差異比較和整合以便形成一個統一的新版本。

5 軟體程式碼的性

　　 由於程式碼完全暴露於所有開發人員面前，任何人都可以增、刪、改之。除了會造成1所提到的不一致問題外，從安全的角度來看，也是存在隱患的，這一點對於一個自主產權的長期開發的產品而言更是如此。即使是一般的專案開發，不同的人員其分工不同，允許別人可以不加限制地任意修改自己負責模組的程式碼（相當於所有人員都具有管理員身份），總是容易產生問題。對於共有模組更是如此，所有人都可以修改，一旦修改，則波及全體。

6 軟體的整合

　　 在軟體的整合過程中，一般比較可靠的做法是使用文字比對工具輔助完成的。這種措施，有以下缺點：

• 可靠性，整合中的人為錯誤會影響軟體的可靠性，有時這種錯誤很難察覺，可能編譯沒有問題，而在測試時卻發現了問題。這種潛在的錯誤發現的時間越晚就越難以糾正。
• 效率，對於純手工的整合即使熟練操作的人也是需要時間來完成的，而有些整合只是將兩段程式碼拼接在一起，這一過程完全可以藉助於某些自動機制。這可以大大節省時間，使開發人員可以專注於後續的開發任務。