论坛首页 Java企业应用论坛

团队出现这样的场景大家一般怎么处理

浏览 49144 次
精华帖 (2) :: 良好帖 (8) :: 新手帖 (0) :: 隐藏帖 (0)
作者 正文
   发表时间:2009-01-13  
我认为定个规矩,首先第一修改之前需要先UPDATE,再进行修改。
第二每天都要养成下班前提交的好习惯。
第三每天都要养成上班前UPDATE的好习惯。

如果有JAR包冲突,在SVN上要养成,统一开发包的好习惯。
(即:JAR包一起放入SVN里面,开发只准用SVN里面的包,如果出现新增包,也应该加入SVN中,以避免后期这种包冲突及兼容问题,也可以提早发现新包存在。)

第四最好是要有所沟通,每次新加入的东西,确定会影响其他模块的话,应该在开发之初就要了解,开发后也要知会相关人员,看是否符合要求。避免后期修改问题。最好能做代码review
(对方很忙的话,也可以口头描述一下)
2 请登录后投票
   发表时间:2009-01-13  
呃 很奇怪为什么我们就没那么多事呢~~
0 请登录后投票
   发表时间:2009-01-13  
因为有相同的感受,所以第一次回复。

1.让团队的成员明白,自己一定要对自己写的代码负责。
2.在任务划分的时候,尽量不要相互之间交叉。
3.在提交svn之前,首先更新工程,并在本地运行,本地通过后方可提交。
4.如果需要增加一些新的jar包(一般不会),统一由项目负责人来增加。其他成员只需更新。
0 请登录后投票
   发表时间:2009-01-13  
csevan 写道
我认为定个规矩,首先第一修改之前需要先UPDATE,再进行修改。
第二每天都要养成下班前提交的好习惯。
第三每天都要养成上班前UPDATE的好习惯。

如果有JAR包冲突,在SVN上要养成,统一开发包的好习惯。
(即:JAR包一起放入SVN里面,开发只准用SVN里面的包,如果出现新增包,也应该加入SVN中,以避免后期这种包冲突及兼容问题,也可以提早发现新包存在。)

第四最好是要有所沟通,每次新加入的东西,确定会影响其他模块的话,应该在开发之初就要了解,开发后也要知会相关人员,看是否符合要求。避免后期修改问题。最好能做代码review
(对方很忙的话,也可以口头描述一下)


说得不错,比较同意你的看法
0 请登录后投票
   发表时间:2009-01-13   最后修改:2009-01-13
合并规则

       代码合并是项目必然要经过的事情. 合并部分最难处理的就是冲突. 这过程也是最容易产生潜在BUG的地方.  有几个地方会发生冲突,

1.        测试合并

在发布测试程序后, 会发生比较严重的冲突行为, 随着测试的进行, 需要解决冲突的地方越来越多. 程序员可能在这种无穷冲突当中感到非常的苦恼. 导致想发布单一的分支进行测试. 此类型问题发生后, 可以根据最新的主干, 建立一个新的项目分支.  然后, 把当前开发的分支合并到新建分支上, 根据该分支进行测试, 开发人员切换到新建分支进行继续开发.  这么样做, 可以保证当前测试是最新主干, 减少回归测试压力.  并减少发布当中可能会出现的冲突出问题.

2.        发布合并

在进行发布过程中如果出现冲突, 不允许在编译机器上解决冲突.  在测试阶段, 持续的使用最新主干建立分支并切换开发分支的形式, 已经杜绝了冲突带进发布环境. 但是, 测试的并一定要求使用和主干合并的情况下, 我们可以做适当的调整, 满足实际开发中过于复杂情况的产生.  因此, 发布过程合并分支持过程要求按如下方式进行:

a)        发布人员必须使用要发布的分支在开发机器测试是否会和主干发生冲突行为.

b)        如果发生冲突, 那就建立从主干建立一个新的分支, 然后把要求发布的分支合并到新建分支.

c)        把新建分支在编译机上合并到主干.


以上是基于分支开发的一些规则。


需要建立一整套的规则。 这只是我的合并规则, 还有:
SVN帐户管理
SVN目录管理
SVN项目管理
SVN主干管理
SVN分支管理

如果这个事情都处理不好, 还当什么程序员。 洗洗回家吧。
开发一定要建立新的分支, 或者在主干。 就3个项目人员要吵架, 要是30个人要互相残杀了? 这个问题首先是项目架构师不作为, 或者项目经理不作为。 基本SVN的规范没有制定, 自己不熟悉SVN操作。

0 请登录后投票
   发表时间:2009-01-13  
csevan 写道
我认为定个规矩,首先第一修改之前需要先UPDATE,再进行修改。
第二每天都要养成下班前提交的好习惯。
第三每天都要养成上班前UPDATE的好习惯。

如果有JAR包冲突,在SVN上要养成,统一开发包的好习惯。
(即:JAR包一起放入SVN里面,开发只准用SVN里面的包,如果出现新增包,也应该加入SVN中,以避免后期这种包冲突及兼容问题,也可以提早发现新包存在。)

第四最好是要有所沟通,每次新加入的东西,确定会影响其他模块的话,应该在开发之初就要了解,开发后也要知会相关人员,看是否符合要求。避免后期修改问题。最好能做代码review
(对方很忙的话,也可以口头描述一下)


   不错,开发团队会面临不同的情况,有的需要远程开发,有的小团队开发,我认为开发模式也会有不同变化。不管有什么样的原则,只要是人来做,就会有不确定性。这样我们努力做到大家都遵守指定的原则,遇到了问题,讨论解决。避免下一次遇到同样的问题,但也要顾虑到组员的感情和开发的效率,毕竟是团队作战。 比如像楼主的问题如果是开发出现了交叉就要考虑任务的分配,如果是引用公共包的冲突就提醒他注意我们的原则等等 。
0 请登录后投票
   发表时间:2009-01-13  
楼主不是华为外包吧。。。

看起来很像啊。。。
0 请登录后投票
   发表时间:2009-01-13  
zhuixinjian 写道
建SVN分支版本!

有SVN还不让人提交,那要SVN干嘛。可以分支版本测试没问题,再合到主版本去!

re
或者试试看git
0 请登录后投票
   发表时间:2009-01-13  
使用SVN有一些基本原则~~比如:产品和开发有分支;上传到SVN的版本可以是未优化,但是应该是可用版本;及时同步等等。

出现你们这个问题,修正一下他们使用svn的习惯,另外,这是人与人之间的问题,最重要沟通协商,大家各让一步找到个都能接受的办法。

另外说个老问题,良好的系统结构也能一定程度避免这样的问题,最简单的尽量使用针对接口编程。减少代码的耦合度和交叉。

A这个哥们也挺神,你修改的东西要保证兼容啊,或者隐藏实现,要避免搞出牵一发动全身的悲剧。。。不够慎重。。。

0 请登录后投票
   发表时间:2009-01-13  
svn上我认为应该是可编译可运行的,每天第一件事就应该先down下最新的版本,然后修改完善自己的模块儿,最后提交前必须保证是可运行的。当然,修改完又提交后也可能会与其他同事新开发的发生冲突,但是这种情况在每天第一次down下来最新版本后就应该发现,这时先找自己的原因,如果确定问题是出在其他的开发人员的模块中,那应该请该同事修正这个问题(这时也许他也找到原因了)。无论如何,我们的目标应该是最终每天提交时,自己机器上的程序是今天下载的最新的,并且是无错的。即使有问题也都能解决在一天的开始阶段,如果每天都会有冲突,或冲突比较多,那应该审察一下团队的沟通了,因为这样的冲突不可能总是出现!
0 请登录后投票
论坛首页 Java企业应用版

跳转论坛:
Global site tag (gtag.js) - Google Analytics