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