一:按模块分配所有权
团队中的每个人在sourcesafe上保留自己的代码，但是自己是看不到未经授权其他人的代码和文档。到发布的时候有SCM(软件配置管理)把大家的代码那到一起编译生成一个版本。也就是说，项目的每一个工件，都是有所有权的，团队成员根据角色划分，每个角色对工件的所有权不同，最少的就是只拥有自己开发的部分的代码和文档。而项目经理或SCM等角色对全部工件有所有权。这样，除了少数几个人外，其他人不能拥有项目的所有代码和文档。
二：集体所有权
这种方式是极限编程中提倡的，团队中的任何人对任何代码都可以签入，签出。没有程序员对某一个特定模块单独负责。所有的模块对所有的人都是开放的。
显然，第一种方式有很多缺点：
1.不利于团队成员间的知识传播。代码没有经过其他人的眼睛，其质量就只能靠 这个模块的负责人了。也许你犯了错误或没有找到更好的实现方法，同样，别人碰到这样的问题， 可能还会重复你的老路。我曾经在几个人的代码中同时发现相同的明显错误，但是没有人认识到这个问题。
2.由于每个模块只由一个人或很少的几个人，那么一旦当这些人离开，由于没有人理解这个模块，工作交接会耗费更多的时间。为了把人变成可替换的零件所采取的过程，却在这里付出了更大的代价，无疑是一种讽刺。
3.底层模块对高层模块形成了更大的影响。或许是怕麻烦，编写高层模块的人经常在使用底层模块旧版本的基础上进行开发，有一天可能突然发现，更新过版本后自己的依赖于底层模块的代码已经无法编译了。底层模块如果发布的很频繁，要保持各个模块间的版本一致，实在是件很烦人的事。而且，每次发布都需要通知每个人。
4.对调试的影响，自己在调用别人的模块的代码中出了错误，到底是自己的错误呢？还是你所依赖的模块的错误？有时很难判断，因为你没有别人的模块的源代码，无法跟踪到内部查看究竟。要么把两部分代码拿到一起来跟踪（很痛苦），要么开始争论（更痛苦）。
5.发布的混乱。如果一个项目有20个模块，在开发初期每个模块平均两天发布一次，SCM可能会被烦死。而且把版本搞混的可能也更大。
第二种方式的优势也是显而易见的。
1.代码对所有人都是开放的，有利于开发人员之间互相取长补短，有利于代码风格的统一，有时会发现几个人写的代码在结构，甚至函数命名都是相同的，这不是一般的代码规范所能限定的。
2.每个人对每个模块都有一定程度的了解，当团队中的成员变动时，就有人能很快接替他的工作。
3.由于每个人每天来都取一次新版本，把各个模块版本一致问题减小到了最小。
4.不管是自己的还是别人的代码，出了问题，跟踪进去看个究竟，比胡乱猜测，询问别人模块的情况要顶用的多。
5.不需要有专门的人来控制版本，每天都有一个新版本，程序员手中的就是最新版本。
要说开放的源代码管理有没有缺点，有，那就是团队之间的磨合需要一段时间，开始的时候可能会产生一些混乱，但是渡过这段时期一般都会比较顺利的。
讨论：
代码安全性何言？如果程序员都拥有所有掌控产品未来的权利，那么大家都是项目经理，从管理角度来看，这不是一个好的做法，原因在于开发前没有做好应有的准备（有一天可能突然发现，更新过版本后自己的依赖于底层模块的代码已经无法编译了，这说明接口定义甚至需求分析都没有完全掌控；在开发初期每个模块平均两天发布一次，SCM可能会被烦死，如果一年发布一次，那么SCM就可以天天放假去旅游；有利于代码风格的统一，这些东西不是编码阶段应该做的，ok?）
换位考虑，开发人员只是项目、产品的一小部分而已。
被CMM搞得烦的多了，受益的也有，眼光不同，悟性不同，受益肯定不同。
虽说CMM现在被批判的很厉害,但是并不是没有可借鉴的东西.
但是有一点,重型过程的项目管理人员总以为对程序员控制的越多,自己就越放心,但是,楼上所说的"晨后综合症"基本只出现在团队建立初期,或者在基础框架还没有稳定的时候.不要以为是给了程序员过多的权利.我经历过一个证券行业的项目,就出现过底层框架修改导致几百个代码文件都要重新编译修改的情况.
还有,楼上所说"开发人员只是项目、产品的一小部分而已",那么一大部分是什么呢?
阅读(1881) | 评论(0) | 转发(0) |
