64,678
社区成员
发帖
与我相关
我的任务
分享几个人一起写代码的时候怎么配合。
现在有个工程，要几个人写。
但是怎么协调呢？
技术都差不多。
现在已经开始了，但是发现我们把一些写好的代码合起来试的时候。
发现出了好多问题。
比如，单独运行OK，但是合到一起就不行了。
合到一起之后发现再改，再合的时候，就出现了代码不同步的问题。
还有很多问题，请各位有团队经验的，给点提示，小弟先谢了。
但是怎么协调呢？
技术都差不多。
现在已经开始了，但是发现我们把一些写好的代码合起来试的时候。
发现出了好多问题。
比如，单独运行OK，但是合到一起就不行了。
合到一起之后发现再改，再合的时候，就出现了代码不同步的问题。
还有很多问题，请各位有团队经验的，给点提示，小弟先谢了。
...全文
请发表友善的回复…
发表回复
kobe198702 2011-03-23
- 打赏
- 举报
接口接口接口接口接口接口接口接口！！！一开始就要设计好！！！
CppCoder 2011-03-23
- 打赏
- 举报
定好规则
分层设计
抽象共同点、封装变化点
定义接口
坐在一起讨论，并形成文档
也不知道说的对不对，一起讨论
分层设计
抽象共同点、封装变化点
定义接口
坐在一起讨论，并形成文档
也不知道说的对不对，一起讨论
direction917 2011-03-23
- 打赏
- 举报
版本控制，各种文档。
wei801516 2011-03-23
- 打赏
- 举报
得定义好一套公共接口。。。下面就好分配咯。。。
cobra_chen 2011-03-23
- 打赏
- 举报
谢谢7楼宝贵意见。
SVN，一直都用的。
不过我觉得还是以前分模块做DLL来的方便，合的时候也方便简单。
感觉上合代码与合DLL没什么区别，但实际操作起来却不是那么简单。
还有就是觉得配合，沟通对于一个团队来说。真的太重要了。即使团队只有2个人。
SVN，一直都用的。
不过我觉得还是以前分模块做DLL来的方便，合的时候也方便简单。
感觉上合代码与合DLL没什么区别，但实际操作起来却不是那么简单。
还有就是觉得配合，沟通对于一个团队来说。真的太重要了。即使团队只有2个人。
莫_问 2011-03-23
- 打赏
- 举报
[Quote=引用 3 楼 healer_kx 的回复:]
SVN用了吗?
模块之间的接口定义好了吗?
线程模型什么的，都商量了吗？
顺便问句，是用UNICODE还是ANSI，之前不会没有商量吧?
[/Quote]
+++
SVN用了吗?
模块之间的接口定义好了吗?
线程模型什么的，都商量了吗？
顺便问句，是用UNICODE还是ANSI，之前不会没有商量吧?
[/Quote]
+++
赵4老师 2011-03-23
- 打赏
- 举报
谁说了算呢？谁发钱谁说了算！(^_^)
cobra_chen 2011-03-23
- 打赏
- 举报
发现，软件设计，比软件编码难多了。
nand库路泽 2011-03-23
- 打赏
- 举报
统一一下大家的命名规则！这样会方便很多！！
赵4老师 2011-03-23
- 打赏
- 举报
别忘了“经济基础决定上层建筑。”
wyfwx 2011-03-23
- 打赏
- 举报
定义好接口,大家都按定义的接口实现
xilin1234 2011-03-23
- 打赏
- 举报
我认为最重要的是把事情协调好，比如A君做什么，B君做什么。另外还要把接口规范好，同时标识符等也应该有着一定的规范！！！
在实际应用中团队合作是非常重要的...
在实际应用中团队合作是非常重要的...
赵4老师 2011-03-23
- 打赏
- 举报
外请或选出一个头，再由头规定
·代码风格
·变量名称、函数接口定义及调用关系
·日志格式
·测试数据及测试方法
·手下的赏罚
·代码风格
·变量名称、函数接口定义及调用关系
·日志格式
·测试数据及测试方法
·手下的赏罚
tangsun1227 2011-03-23
- 打赏
- 举报
1 按交付的功能划分职责，定义接口
2 持续集成
2 持续集成
Defonds 2011-03-23
- 打赏
- 举报
svn、cvs。。。做好分支、维护
积木 2011-03-23
- 打赏
- 举报
。。。。。估计就是校内的某一个小团队，没学过软件工程的。。。
stephenliu2011 2011-03-23
- 打赏
- 举报
的确很麻烦啊 要有一个leader定义接口规范等等
lovesi3344 2011-03-23
- 打赏
- 举报
极限编程
走好每一步 2011-03-23
- 打赏
- 举报
尽量两个人做的东西关联不大吧。
隔一段时间就合在一起，再两个人基于合的版本继续做，这样会减少很多麻烦吧。
隔一段时间就合在一起，再两个人基于合的版本继续做，这样会减少很多麻烦吧。
pathuang68 2011-03-22
- 打赏
- 举报
适当概要设计文档和详细设计文档还是必要的。对于非正式或者客户未要求提供完整的文档的项目而言：
1. 概要设计文档，主要提供功能模块划分，各模块之间的关系、采用的技术路线(包括编程语言、操作系统、数据库系统...)
2. 详细设计文档，主要包括定义各模块之间的接口函数或方法(比如返回值类型，函数的名称，参数的个数及其名称、类型)，数据库物理模型(即数据库表结构、字段名称、数据类型、大小)
3. 根据模块划分，进行分工；
4. 组员中任何人都可以提出1,2中的修改意见，但必须要大家一起讨论并通过，才能修改，并要尽快Update相关文档，同时知会所有的参与人员。
5. 使用软件配置管理工具，如SVN, VSS都是很好的习惯，但不是必须的。
6. 使用错误跟踪管理工具，如Bugzilla也是很好的习惯，但也不是必须的。
7. 即便你们认真做到了上面的1到6条，联合调试的时候，仍然会出现意想不到的问题，这其实是很正常的，所有的项目都是这样，不管是M$，还是Google，或者Oracle，或者IBM或者whatever。
1. 概要设计文档，主要提供功能模块划分，各模块之间的关系、采用的技术路线(包括编程语言、操作系统、数据库系统...)
2. 详细设计文档，主要包括定义各模块之间的接口函数或方法(比如返回值类型，函数的名称，参数的个数及其名称、类型)，数据库物理模型(即数据库表结构、字段名称、数据类型、大小)
3. 根据模块划分，进行分工；
4. 组员中任何人都可以提出1,2中的修改意见，但必须要大家一起讨论并通过，才能修改，并要尽快Update相关文档，同时知会所有的参与人员。
5. 使用软件配置管理工具，如SVN, VSS都是很好的习惯，但不是必须的。
6. 使用错误跟踪管理工具，如Bugzilla也是很好的习惯，但也不是必须的。
7. 即便你们认真做到了上面的1到6条，联合调试的时候，仍然会出现意想不到的问题，这其实是很正常的，所有的项目都是这样，不管是M$，还是Google，或者Oracle，或者IBM或者whatever。
加载更多回复（6）
