并行工程师什么，这里就不再解释（不懂请百度），实际上，在软件开发过程中，涉及到多人合作的以项目小组形式完成开发的软件（这里指广义上）或多或少都使用了并行工程的概念，在正式的项目开发中，项目小组成员总是分工合作每人完成一部分，然后再合并起来，而且，在实际应用中，尽管使用的是瀑布模型完成开发，但总是所有项目小组成员同时开始完成自己的部分，这，其实已经是并行工程了，我们可以自豪的宣布：我们在开发过程中使用了并行 工程这种高大上的玩意来提高开发速度，所以，老板你得给我们涨工资！

很简单吧，看起来好简单的样子，但是实际上呢？要是想用上面那句话找老板涨工资，老板绝对喷你一脸，然后回一句：这种简单的分工合作也叫并行工程？你当我数理化老师通通是体育老师兼职吗！是的，简单的分工合作并不能称之为并行工程，从并行工程的概念上看是有点样子，但从要求上看，还差得远，那么在软件开发过程中到底如何使用并行工程呢？很简单的事情：找出使用并行工程的条件然后满足他就可以了！很简单吧，是的，喝杯咖啡庆祝一下吧，庆祝我们失业了。

当然，满足并行工程的条件这种说法并没有错，鉴于软件开发中各种代码互相调用的复杂性，通常意义上说就是什么API调用啊，模块调用啊什么的，导致就目前而言软件开发过程中基本上都是使用的瀑布模型，也就是一步一步的来，简化一下过程可以看做：需求分析-》功能设计-》代码编写-》测试-》使用和维护；这五个步奏基本上就代表了整个开发过程，而且每一个步奏的开始条件都是上一个步奏完成以后，也就是说，这种传承模式下根本就没法搞并行，就算是要并行也只能是步奏内并行，这对于提高项目开发速度有作用，但作用并不大，也就是说想要搞有效果的并行，就需要改变这个步奏，怎么改呢？首先，需求分析是肯定不能改的，毕竟要做出什么东西肯定要分析需求，最后一个使用和维护肯定也是不能改的，能动手的也就中间三个步奏，怎么改呢？从实际情况出发，功能设计这块是可以拆分的，因为肯定不止有一个功能，而要实现一个功能又要实现若干个子功能，于是，我们开始从这里下手，怎么改？这是个问题。

我们知道，在CPU执行指令的过程是：取指令，执行指令，而CPU为了加快这一过程使用了流水线，这里我们可以借鉴一下，不过，不是借鉴流水线，而是借鉴这种思想，我们可以对功能设计这块进行拆分，联合需求分析这块，当需求分析给出一个需求时，就开始进行功能设计，功能设计完成就直接进入代码编写和测试，这样每提出一个需求就直接一路走下去直接进入测试，如果将这个过程看做一条流水线，那么么，整个开发过程有多少需求就有多少流水线，当开发人员足够多时，多条流水线齐头并进，一下子就进入使用和维护阶段。

这就是搞并行工程的理论基础，实际上，不论并行工程用在哪方面，具体步奏都差不多，只是根据项目类别不同而有所变化，但核心思想就是多路开工，齐头并进。现在理论基础已经完成，实际效果如何呢，结果是很麻烦，因为软件开发的特殊性，经常出现跨路径引用、调用，甚至跨主机都不是什么新鲜事，这也就导致了源代码之间的关系非常紧密，有时甚至只修改了一个字母就会导致不能编译，这种情况之下搞并行是非常困难的，即使有指导性稳定和技术规范文档，但由于人与人之间性格的差异性，即使在同一个指导性文档下做出来的东西一不一样，同一开发组的成员还好说，面对面交流可以解决这个麻烦，但是一旦项目大了，涉及到的项目小组或者开发人员过多，甚至开发小组本身就是通过网络开发的情况下，根本无法解决差异性的问题，最后的结果就是搞并行麻烦多多，还不如不搞。也就是说，软件开发中真要搞并行工程，必须要解决这个问题！差异性问题不解决，并行就是个笑话。

基于这个问题，提出了模块化这个概念，具体实现过程是，对于一个功能模块，能不依赖其他同级或上级模块独立运行，可以依赖于子模块，但只能依赖于本身的子模块，也就是说，模块拥有完整的功能库（我无法准确的表达这个概念，具体意思为模块拥有完整的，独立的组件，包括图标、运行库、链接库等）这样做是为了打破源代码中互相调用情况，只有彼此独立了，并行才可以进行下去。（关于模块化设计，我参考了一部分互联网的资料，部分资料来源与建筑行业，可以说这里的模块与其他行业上的模块概念上没有很大的差距）

解决了源代码互相依赖，互相调用的问题，接下来要干嘛呢？只有一件事了，那就是拆分，对整个项目的拆分，一个项目拆分成若干个功能模块，然后这些功能模块又被拆分成若干个子模块……直到被拆分成一个个不能再拆分的基础模块甚至函数为止，这个时候，整个项目实际上已经变成了一个个基础模块的集合，当所有的被拆分出来的模块被完成时，项目就完成了，也许这时你要说我在这个过程中没有看到并行工程啊，什么！！都到这里了还不知道怎么搞？找一大堆人过来一起完成这些模块啊！这还不并行怎么才能算并行？模块太多人太少？发布悬赏啊亲，让全国这么多程序员赚点外快嘛，怎么发布悬赏？有git啊亲！

恩，并行工程的所有问题都解决了，接下来讲讲怎么让这个东西基于git被开发出来，我们知道，git这个东西严格来讲其地址指向的不是文件，而是文件夹，这样问题就好解决了，每创建一个子模块就在这个项目的主文件夹内创建对应的文件夹就OK了，然后将这个文件夹作为一个独立项目重新指向，当然，这其中有权限问题，也有当项目完成时子模块合并的问题，但这个问题并不是问题，只要在主项目中做好说明就可以了（类似于编辑Makefile文件）

我想，基于git开发出这个东西并不是问题，哦，还有版本控制的问题，毕竟模块化了以后，肯定同一模块会有不同版本，不然怎么升级好忽悠钱？所以同样带有一个版本库，所谓的版本库其实也是一个晚上文件夹，只不过这个文件夹是用版本号命名的，至于新版本模块使用老版本子模块代码的问题，简单啊，直接复制过来就是的，源码本身又没有多大，就算很大，以现在的条件来讲，储存空间会是问题吗？

不过，并行虽然并行了，但会导致两个问题，一个就是最终成品会比较大，毕竟以前没有模块化时很多资源可以共享，但模块化后就不存在共享资源了，每个模块的资源都是独享的，所以模块化时要求就是尽可能使用操作系统提供个的共享库和动态链接库，尽可能的减少独享资源的数量；二就是安全性问题，毕竟模块多而且模块间彼此独立，这也就有可能出现所有的模块在安全性上没有问题，但组合起来却有问题（不要怀疑，window系统本身就是个例子）。

基于git的软件开发中并行工程管理以及版本控制系统概要