- 关 键 词:
原文见:说说对两种源代码管理方式的感受
一:按模块分配所有权
二:集体所有权
这种方式是极限编程中提倡的,团队中的任何人对任何代码都可以签入,签出。没有程序员对某一个特定模块单独负责。所有的模块对所有的人都是开放的。
显然,第一种方式有很多缺点:
1.不利于团队成员间的知识传播。代码没有经过其他人的眼睛,其质量就只能靠 这个模块的负责人了。也许你犯了错误或没有找到更好的实现方法,同样,别人碰到这样的问题, 可能还会重复你的老路。我曾经在几个人的代码中同时发现相同的明显错误,但是没有人认识到这个问题。
2.由于每个模块只由一个人或很少的几个人,那么一旦当这些人离开,由于没有人理解这个模块,工作交接会耗费更多的时间。为了把人变成可替换的零件所采取的过程,却在这里付出了更大的代价,无疑是一种讽刺。
3.底层模块对高层模块形成了更大的影响。或许是怕麻烦,编写高层模块的人经常在使用底层模块旧版本的基础上进行开发,有一天可能突然发现,更新过版本后自己的依赖于底层模块的代码已经无法编译了。底层模块如果发布的很频繁,要保持各个模块间的版本一致,实在是件很烦人的事。而且,每次发布都需要通知每个人。
4.对调试的影响,自己在调用别人的模块的代码中出了错误,到底是自己的错误呢?还是你所依赖的模块的错误?有时很难判断,因为你没有别人的模块的源代码,无法跟踪到内部查看究竟。要么把两部分代码拿到一起来跟踪(很痛苦),要么开始争论(更痛苦)。
5.发布的混乱。如果一个项目有20个模块,在开发初期每个模块平均两天发布一次,SCM可能会被烦死。而且把版本搞混的可能也更大。
第二种方式的优势也是显而易见的。
1.代码对所有人都是开放的,有利于开发人员之间互相取长补短,有利于代码风格的统一,有时会发现几个人写的代码在结构,甚至函数命名都是相同的,这不是一般的代码规范所能限定的。
2.每个人对每个模块都有一定程度的了解,当团队中的成员变动时,就有人能很快接替他的工作。
3.由于每个人每天来都取一次新版本,把各个模块版本一致问题减小到了最小。
4.不管是自己的还是别人的代码,出了问题,跟踪进去看个究竟,比胡乱猜测,询问别人模块的情况要顶用的多。
5.不需要有专门的人来控制版本,每天都有一个新版本,程序员手中的就是最新版本。
要说开放的源代码管理有没有缺点,有,那就是团队之间的磨合需要一段时间,开始的时候可能会产生一些混乱,但是渡过这段时期一般都会比较顺利的。 巧 巧 读 书:http://www.qqread.com/other-devtool/v204111002.html
相关图文阅读
频道图文推荐
健 康 咨 询
时 尚 咨 询
相关专题
- 网络管理实用手册 (22492篇文章)
- BPEL的基本思想 (1次浏览)
- Windows CE 6.0的技术发展与突破 (0次浏览)
- 动态和静态程序设计语言的可伸缩性 (0次浏览)
- 在Shell中执行vi/cp/mv时自动备份源文件 (0次浏览)



