基於git的軟體開發中並行工程管理以及版本控制系統概要

標籤：使用   檔案   問題   c   代碼   ef   管理   應用   window   

並行工程師什麼，這裡就不再解釋（不懂請百度），實際上，在軟體開發過程中，涉及到多人合作的以項目小組形式完成開發的軟體（這裡指廣義上）或多或少都使用了並行工程的概念，在正式的項目開發中，項目小組成員總是分工合作每人完成一部分，然後再合并起來，而且，在實際應用中，儘管使用的是瀑布模型完成開發，但總是所有項目小組成員同時開始完成自己的部分，這，其實已經是並行工程了，我們可以自豪的宣布：我們在開發過程中使用了並行 工程這種高大上的玩意來提高開發速度，所以，老闆你得給我們漲工資！

很簡單吧，看起來好簡單的樣子，但是實際上呢？要是想用上面那句話找老闆漲工資，老闆絕對噴你一臉，然後回一句：這種簡單的分工合作也叫並行工程？你當我數理化老師通通是體育老師兼職嗎！是的，簡單的分工合作並不能稱之為並行工程，從並行工程的概念上看是有點樣子，但從要求上看，還差得遠，那麼在軟體開發過程中到底如何使用並行工程呢？很簡單的事情：找出使用並行工程的條件然後滿足他就可以了！很簡單吧，是的，喝杯咖啡慶祝一下吧，慶祝我們失業了。

當然，滿足並行工程的條件這種說法並沒有錯，鑒於軟體開發中各種代碼互相調用的複雜性，通常意義上說就是什麼API調用啊，模組調用啊什麼的，導致就目前而言軟體開發過程中基本上都是使用的瀑布模型，也就是一步一步的來，簡化一下過程可以看做：需求分析-》功能設計-》代碼編寫-》測試-》使用和維護；這五個步奏基本上就代表了整個開發過程，而且每一個步奏的開始條件都是上一個步奏完成以後，也就是說，這種傳承模式下根本就沒法搞並行，就算是要並行也只能是步奏內並行，這對於提高項目開發速度有作用，但作用並不大，也就是說想要搞有效果的並行，就需要改變這個步奏，怎麼改呢？首先，需求分析是肯定不能改的，畢竟要做出什麼東西肯定要分析需求，最後一個使用和維護肯定也是不能改的，能動手的也就中間三個步奏，怎麼改呢？從實際情況出發，功能設計這塊是可以拆分的，因為肯定不止有一個功能，而要實現一個功能又要實現若干個子功能，於是，我們開始從這裡下手，怎麼改？這是個問題。

我們知道，在CPU執行指令的過程是：取指令，執行指令，而CPU為了加快這一過程使用了流水線，這裡我們可以借鑒一下，不過，不是借鑒流水線，而是借鑒這種思想，我們可以對功能設計這塊進行拆分，聯合需求分析這塊，當需求分析給出一個需求時，就開始進行功能設計，功能設計完成就直接進入代碼編寫和測試，這樣每提出一個需求就直接一路走下去直接進入測試，如果將這個過程看做一條流水線，那麼麼，整個開發過程有多少需求就有多少流水線，當開發人員足夠多時，多條流水線齊頭並進，一下子就進入使用和維護階段。

這就是搞並行工程的理論基礎，實際上，不論並行工程用在哪方面，具體步奏都差不多，只是根據項目類別不同而有所變化，但核心思想就是多路開工，齊頭並進。現在理論基礎已經完成，實際效果如何呢，結果是很麻煩，因為軟體開發的特殊性，經常出現跨路徑引用、調用，甚至跨主機都不是什麼新鮮事，這也就導致了原始碼之間的關係非常緊密，有時甚至只修改了一個字母就會導致不能編譯，這種情況之下搞並行是非常困難的，即使有指導性穩定和技術規範文檔，但由於人與人之間性格的差異性，即使在同一個指導性文檔下做出來的東西一不一樣，同一開發組的成員還好說，面對面交流可以解決這個麻煩，但是一旦項目大了，涉及到的項目小組或者開發人員過多，甚至開發小組本身就是通過網路開發的情況下，根本無法解決差異性的問題，最後的結果就是搞並行麻煩多多，還不如不搞。也就是說，軟體開發中真要搞並行工程，必須要解決這個問題！差異性問題不解決，並行就是個笑話。

基於這個問題，提出了模組化這個概念，具體實現過程是，對於一個功能模組，能不依賴其他同級或上級模組獨立運行，可以依賴於子模組，但只能依賴於本身的子模組，也就是說，模組擁有完整的功能庫（我無法準確的表達這個概念，具體意思為模組擁有完整的，獨立的組件，包括表徵圖、運行庫、連結庫等）這樣做是為了打破原始碼中互相調用情況，只有彼此獨立了，並行才可以進行下去。（關於模組化設計，我參考了一部分互連網的資料，部分資料來源與建築行業，可以說這裡的模組與其他行業上的模組概念上沒有很大的差距）

解決了原始碼互相依賴，互相調用的問題，接下來要幹嘛呢？只有一件事了，那就是拆分，對整個項目的拆分，一個項目拆分成若干個功能模組，然後這些功能模組又被拆分成若干個子模組……直到被拆分成一個個不能再拆分的基礎模組甚至函數為止，這個時候，整個項目實際上已經變成了一個個基礎模組的集合，當所有的被拆分出來的模組被完成時，項目就完成了，也許這時你要說我在這個過程中沒有看到並行工程啊，什麼！！都到這裡了還不知道怎麼搞？找一大堆人過來一起完成這些模組啊！這還不並行怎麼才能算並行？模組太多人太少？發布懸賞啊親，讓全國這麼多程式員賺點外快嘛，怎麼發布懸賞？有git啊親！

恩，並行工程的所有問題都解決了，接下來講講怎麼讓這個東西基於git被開發出來，我們知道，git這個東西嚴格來講其地址指向的不是檔案，而是檔案夾，這樣問題就好解決了，每建立一個子模組就在這個項目的主資料夾內建立對應的檔案夾就OK了，然後將這個檔案夾作為一個獨立項目重新指向，當然，這其中有許可權問題，也有當項目完成時子模組合并的問題，但這個問題並不是問題，只要在主專案中做好說明就可以了（類似於編輯Makefile檔案）

我想，基於git開發出這個東西並不是問題，哦，還有版本控制的問題，畢竟模組化了以後，肯定同一模組會有不同版本，不然怎麼升級好忽悠錢？所以同樣帶有一個版本庫，所謂的版本庫其實也是一個晚上檔案夾，只不過這個檔案夾是用版本號碼命名的，至於新版本模組使用老版本子模組代碼的問題，簡單啊，直接複製過來就是的，源碼本身又沒有多大，就算很大，以現在的條件來講，儲存空間會是問題嗎？

不過，並行雖然並行了，但會導致兩個問題，一個就是最終成品會比較大，畢竟以前沒有模組化時很多資源可以共用，但模組化後就不存在共用資源了，每個模組的資源都是獨享的，所以模組化時要求就是儘可能使用作業系統提供個的共用庫和動態連結程式庫，儘可能的減少獨享資源的數量；二就是安全性問題，畢竟模組多而且模組間彼此獨立，這也就有可能出現所有的模組在安全性上沒有問題，但組合起來卻有問題（不要懷疑，window系統本身就是個例子）。

基於git的軟體開發中並行工程管理以及版本控制系統概要