以下内容纯属根据真实故事改编。
公司业务发展,程序员一下子组了个足球队,代码管理成了最大的问题,因为之前人少大家都习惯单挑,一个人搞定了coding,编译,发布,甚是牛逼。随着程序员足球队的壮大,大家发现解决问题的效率更低了。主要表现为:
1.大牛解决了问题不告诉你,他一个人干完了所有的事(包括但不局限于log加上自己的名字), 当发布版本时才发现你的问题还没有解决,需要他重新出版本。效率低下。
2.同样的问题每个人都解决一遍,于是1+1有11个结果。没有标准。
3.代码满天飞,u盘里装满了代码,但是不知道哪个是最新的,功能最全的。没有版本。
基于以上足球队常犯的错误,于是诞生了配置管理工程师—作用主管代码。
配置工程师一上任,搭建git/搭建编译环境/搭建Jenkins,代码管理V1.0上线。
代码管理V1.0
V1.0使用了差异化覆盖的构建架构。建立差异化目录,在编译时覆盖到基础代码中。通过这种方式来实现客制化差异。于是大家爽了,再也不用低声下气拷贝粘贴别人的代码了。因为每个队员的代码都被统一上传到了服务器,所有的改动大家都可见。查找版本问题也可以对照修改点判断自己是不是背锅侠。
好景不常在,问题经常有!
V1.0 code拷贝方式发现的问题
(1)工程师修改代码时,每次都需要将原始目录下的文件拷贝一份到code差异目录下修改,增加了工作量。
(2)执行拷贝脚本后原始目录下会有很多文件处于修改状态,不利于工程师检查自己修改的文件是否正确(可以在code差异目录下检查,但最终参加编译的是原始目录下的文件,两者不能完全等同)。比如:原始目录下已经存在某个应用的代码,但开发人员不清楚,在code差异目录下添加了同名的应用的代码(内容跟原始目录下不同),拷贝过去之后只有部分文件被覆盖,导致代码混乱。但由于原始目录下太多文件处于修改状态,开发人员不好检查发现这个问题。
(3)用Source Insight等工具浏览代码时,每次都会发现原始目录和code差异目录会有同名的文件 ,为修改代码带来一些不便,增加了出错的可能。
(4)一个项目一套代码,一套代码又有很多差异化目录,长此以往猿将不码。
为了解决以上问题,下期将讲解V2.0的故事,敬请您收看。
如若转载,请注明出处:https://www.daxuejiayuan.com/12654.html