基于git的軟件開發中并行工程管理
并行工程是什么，這里就不再解釋（不懂請百度），實際上，在軟件開發過程中，涉及到多人合作的以項目小組形式完成開發的軟件（這里指廣義上）或多或少都使用了并行工程的概念，在正式的項目開發中，項目小組成員總是分工合作每人完成一部分，然后再合并起來，而且，在實際應用中，盡管使用的是瀑布模型完成開發，但總是所有項目小組成員同時開始完成自己的部分，這，其實已經是并行工程了，我們可以自豪的宣布：我們在開發過程中使用了并行 工程這種高大上的玩意來提高開發速度，所以，老板你得給我們漲工資！
很簡單吧，看起來好簡單的樣子，但是實際上呢？要是想用上面那句話找老板漲工資，老板絕對噴你一臉，然后回一句：這種簡單的分工合作也叫并行工程？你當我數理化老師通通是體育老師兼職嗎！是的，簡單的分工合作并不能稱之為并行工程，從并行工程的概念上看是有點樣子，但從要求上看，還差得遠，那么在軟件開發過程中到底如何使用并行工程呢？很簡單的事情：找出使用并行工程的條件然后滿足他就可以了！很簡單吧，是的，喝杯咖啡慶祝一下吧，慶祝我們失業了。
當然，滿足并行工程的條件這種說法并沒有錯，鑒于軟件開發中各種代碼互相調用的復雜性，通常意義上說就是什么API調用啊，模塊調用啊什么的，導致就目前而言軟件開發過程中基本上都是使用的瀑布模型，也就是一步一步的來，簡化一下過程可以看做：需求分析-》功能設計-》代碼編寫-》測試-》使用和維護；這五個步奏基本上就代表了整個開發過程，而且每一個步奏的開始條件都是上一個步奏完成以后，也就是說，這種傳承模式下根本就沒法搞并行，就算是要并行也只能是步奏內并行，這對于提高項目開發速度有作用，但作用并不大，也就是說想要搞有效果的并行，就需要改變這個步奏，怎么改呢？首先，需求分析是肯定不能改的，畢竟要做出什么東西肯定要分析需求，***一個使用和維護肯定也是不能改的，能動手的也就中間三個步奏，怎么改呢？從實際情況出發，功能設計這塊是可以拆分的，因為肯定不止有一個功能，而要實現一個功能又要實現若干個子功能，于是，我們開始從這里下手，怎么改？這是個問題。
我們知道，在CPU執行指令的過程是：取指令，執行指令，而CPU為了加快這一過程使用了流水線，這里我們可以借鑒一下，不過，不是借鑒流水線，而是借鑒這種思想，我們可以對功能設計這塊進行拆分，聯合需求分析這塊，當需求分析給出一個需求時，就開始進行功能設計，功能設計完成就直接進入代碼編寫和測試，這樣每提出一個需求就直接一路走下去直接進入測試，如果將這個過程看做一條流水線，那么么，整個開發過程有多少需求就有多少流水線，當開發人員足夠多時，多條流水線齊頭并進，一下子就進入使用和維護階段。
這就是搞并行工程的理論基礎，實際上，不論并行工程用在哪方面，具體步奏都差不多，只是根據項目類別不同而有所變化，但核心思想就是多路開工，齊頭并進。現在理論基礎已經完成，實際效果如何呢，結果是很麻煩，因為軟件開發的特殊性，經常出現跨路徑引用、調用，甚至跨主機都不是什么新鮮事，這也就導致了源代碼之間的關系非常緊密，有時甚至只修改了一個字母就會導致不能編譯，這種情況之下搞并行是非常困難的，即使有指導性穩定和技術規范文檔，但由于人與人之間性格的差異性，即使在同一個指導性文檔下做出來的東西一不一樣，同一開發組的成員還好說，面對面交流可以解決這個麻煩，但是一旦項目大了，涉及到的項目小組或者開發人員過多，甚至開發小組本身就是通過網絡開發的情況下，根本無法解決差異性的問題，***的結果就是搞并行麻煩多多，還不如不搞。也就是說，軟件開發中真要搞并行工程，必須要解決這個問題！差異性問題不解決，并行就是個笑話。
基于這個問題，提出了模塊化這個概念，具體實現過程是，對于一個功能模塊，能不依賴其他同級或上級模塊獨立運行，可以依賴于子模塊，但只能依賴于本身的子模塊，也就是說，模塊擁有完整的功能庫（我無法準確的表達這個概念，具體意思為模塊擁有完整的，獨立的組件，包括圖標、運行庫、鏈接庫等）這樣做是為了打破源代碼中互相調用情況，只有彼此獨立了，并行才可以進行下去。（關于模塊化設計，我參考了一部分互聯網的資料，部分資料來源與建筑行業，可以說這里的模塊與其他行業上的模塊概念上沒有很大的差距）
解決了源代碼互相依賴，互相調用的問題，接下來要干嘛呢？只有一件事了，那就是拆分，對整個項目的拆分，一個項目拆分成若干個功能模塊，然后這些功能模塊又被拆分成若干個子模塊……直到被拆分成一個個不能再拆分的基礎模塊甚至函數為止，這個時候，整個項目實際上已經變成了一個個基礎模塊的集合，當所有的被拆分出來的模塊被完成時，項目就完成了，也許這時你要說我在這個過程中沒有看到并行工程啊，什么！！都到這里了還不知道怎么搞？找一大堆人過來一起完成這些模塊啊！這還不并行怎么才能算并行？模塊太多人太少？發布懸賞啊親，讓全國這么多程序員賺點外快嘛，怎么發布懸賞？有git啊親！
恩，并行工程的所有問題都解決了，接下來講講怎么讓這個東西基于git被開發出來，我們知道，git這個東西嚴格來講其地址指向的不是文件，而是文件夾，這樣問題就好解決了，每創建一個子模塊就在這個項目的主文件夾內創建對應的文件夾就OK了，然后將這個文件夾作為一個獨立項目重新指向，當然，這其中有權限問題，也有當項目完成時子模塊合并的問題，但這個問題并不是問題，只要在主項目中做好說明就可以了（類似于編輯Makefile文件）
我想，基于git開發出這個東西并不是問題，哦，還有版本控制的問題，畢竟模塊化了以后，肯定同一模塊會有不同版本，不然怎么升級好忽悠錢？所以同樣帶有一個版本庫，所謂的版本庫其實也是一個晚上文件夾，只不過這個文件夾是用版本號命名的，至于新版本模塊使用老版本子模塊代碼的問題，簡單啊，直接復制過來就是的，源碼本身又沒有多大，就算很大，以現在的條件來講，儲存空間會是問題嗎？
不過，并行雖然并行了，但會導致兩個問題，一個就是最終成品會比較大，畢竟以前沒有模塊化時很多資源可以共享，但模塊化后就不存在共享資源了，每個模塊的資源都是獨享的，所以模塊化時要求就是盡可能使用操作系統提供個的共享庫和動態鏈接庫，盡可能的減少獨享資源的數量；二就是安全性問題，畢竟模塊多而且模塊間彼此獨立，這也就有可能出現所有的模塊在安全性上沒有問題，但組合起來卻有問題（不要懷疑，window系統本身就是個例子）。
