C#项目做和合的问题

版本管理软件只是一个工作，他不能体现你的架构，项目合并和它并没有本质的关系。
b/s站点的好处不用我讲了，可以跨站点相互交流，实现信息的共享及操作的连惯性。

但是多个站点有时并不实用，比如你的每个组员所做的内容功能都及少，这也用到多站点的话，有时就多出了不必要的麻烦，权限验证等等。
而如果一个站点大家就怕彼此代码的耦合度太高，导至出错。可是这些都是不可辟免的，这样对你的当时系统架构有极高的要求。个人给你一个建议，如果认为自己的架构能力有限，那么你就要求你的组员，除了数据库实体，及数据层共享外，其它的要求他们一律自己建自己的文件，并且在不同的层中把自己的文件都放到自己定义的类中。这样合起来冲突不大，并且要求每一个人把这个类层级的类名报给你，你可以统一定一下，只要这层不冲突下面随便写，最后合起来也无所谓。这种方式一直到界面展示层，ok.就可以了。

真正的王道，那就是做一个标准的架构，把功能细化，并能很好的功能模块化，功能间是松耦合，按功能建类视图。等等吧，具体我也是菜菜了。乱谈的。呵呵。

最忌讳的就是前期需求分析不充分
数据库一般在编码前都已经确定的，最好不要有大的改动，常用的方法是在表中多留几个备用字段，以便适应将来改动
然后就是系统框架要搭好，比如分层，分包等等，防止冲突，也便于维护
另外就是使用svn或cvs做版本控制，协同工作。
记得我刚进公司的第一件事就是培训svn

我们做项目都是用svn，就是版本控制，有一台服务器主机，各有分工做自己的部分，自己的部分都是在本地上令箭项目测试，完成后再像主机的那个项目整合。每天早上先开会，总结昨天自己做好的工作并用投影仪给大家演示成果，每个人都说完了就听管技术的组长或者老板安排今天要完成的内容，还是先将服务器上的项目下载到本地在本地上写自己的部分，通过测试，再网服务器上整合，svn的特点就是lock上了项目的文件其他人就不能用了，所以不会覆盖他人的劳动成果，一般谁什么时候要用主机上的文件会跟组长和大家说一声，就不会冲突了。