比较好奇比较大型的项目是如何协作的，我这一直在小公司呆着，也没见识过，有个能参观一下也不错啊，涨涨见识。

见识

涨涨

协作

好奇

22 条回复 • 2019-01-31 08:21:00 +08:00

1

choury

2019-01-30 10:21:20 +08:00

1

你参观下 linux 或者 chromium 不就行了

2

kidult

2019-01-30 10:22:16 +08:00

有啥好看的，项目经理和项目经理天天在撕逼呗

越是大的项目，效率越低

3

westoy

2019-01-30 10:23:31 +08:00

《人月神话》

4

webjin1

2019-01-30 10:25:50 +08:00 via Android

大型项目≠大公司
小型项目≠小公司
很多开源项目人家就没公司。
大公司我也没去过，但是上门送过一次东西去大型公司有幸见识到，比大型网吧都有大，工位特多。但是里面不吵都很安静。

5

Greenm

2019-01-30 10:26:32 +08:00

5

https://github.com/rapid7/metasploit-framework 这个项目应该不算小了。

基本的项目协作流程就是代码全通过新开分支，Pull Request 提交，任何人可以 code review，有权限的人来负责合并。所有的改动都由 PR 来实现。

大体上就是这样，还有一些其他的，比如 CI 测试、代码规范、写 commit 的要求等等就属于比较细节的东西了。整体说来这个项目的流程非常规范合理，值得学习。

6

xomix

2019-01-30 10:31:22 +08:00

我这几天才被领导教训过，因为我先写实体方法再写接口，他说如果我先写出来接口，那么调用方就可以开始利用依赖注入写代码了，我方法写完大家联调就行了，我感觉是还可以这样！！！

7

yanaraika

2019-01-30 10:31:27 +08:00 via Android

就说 chromium 吧，基本操作是所有走 PR + Review + 高测试覆盖率 + 静态分析 /动态检查 /fuzzing 全家桶，当然最重要的是控制贡献者的水平与整体风格。chromium 能搞起来的根本原因是 Google 往里面砸了很多钱，能招到一流的工程师+提供软硬件支持

8

loveCoding

2019-01-30 10:36:41 +08:00

一般是一个小需求开一个 feature 分支 ,从头做到尾,最后 code review 合并到主分支

9

xiaoxinshiwo

2019-01-30 10:39:49 +08:00

3

项目大，撕逼和甩锅就多，天天发邮件抄送对方领导

10

meteor957

2019-01-30 10:42:10 +08:00

战略性收藏

11

aitaii

2019-01-30 10:46:01 +08:00

1

@xiaoxinshiwo 抄送领导是精髓

12

onec

2019-01-30 10:48:04 +08:00 via Android

靠吼

13

markyun

2019-01-30 10:50:36 +08:00

1

我们前端多人协作，各自开发功能模块，会互相 review code，会提取公共组件。

之前使用 fork + pull requests 分支模式。现在使用分支开发模式，大概分为这些；

上线主分支 master
开发主分支 develop
大功能块分支 feature
bug 分支 fixbug
周期迭代版本 sprint
预发布分支 release

14

markyun

2019-01-30 10:51:03 +08:00

我们前端多人协作，各自开发功能模块，会互相 review code，会提取公共组件。

之前使用 fork + pull requests 分支模式。现在使用分支开发模式，大概分为这些；

上线主分支 master
开发主分支 develop
大功能块分支 feature
bug 分支 fixbug

大概就这样~

15

passerbytiny

2019-01-30 10:55:24 +08:00 via iPhone

前提，CMMI、ISO9001，或者二者都有。工程方法：已过时的瀑布式流程；兴起过一段的迭代（小瀑布式）流程；现行各种敏捷过程。

16

darktutu

OP

2019-01-30 11:05:35 +08:00

@passerbytiny 每个过程感觉在每个公司落地的还是不一样的，虽然可能都是瀑布或者敏捷。
@markyun 只能看明白个大概，没用过所以都无法理解啊。。不是真是操作还是理解不够好啊

17

hymxm

2019-01-30 11:15:16 +08:00

@xiaoxinshiwo #9 哈哈哈真实

18

sighforever

2019-01-30 15:56:18 +08:00

@passerbytiny
我觉得现在都是基于短时间迭代的项目了，这些上古时代的软件工程没啥用

19

jsq2627

2019-01-30 17:19:42 +08:00

@sighforever #18 需要保障一次交付质量的场景，例如外包、关键专业领域，没法敏捷迭代的

20

msg7086

2019-01-31 00:56:48 +08:00

@xomix #6 这其实就是 BDD，面向行为驱动。先规定你的程序表现如何，然后再用代码实现它。

21

ecloud

2019-01-31 02:47:12 +08:00 via iPhone

吵架，吵架，吵架
开会，开会，开会
跟开发吵，跟测试吵，跟 PM 吵，跟客户吵，最后是跟大老板吵

当年在 IBM 做 IVT，有种当联合国秘书长的赶脚。看谁都不顺眼，一轮测试下来开出十几个 PMR，心里总在怀疑我怎么跟一群猪做同事。
一封邮件 CC 十几个人，内容写得像审判书。各种前因后果，截图日志，引用某某对话，逻辑分析，推倒，假设。最后一段是判决，和诚恳的请求，请求大家以后能张点心，请求看邮件的人先认真读完审判书再回信狡辩。

我的测试环境一共由 13 台服务器组成，运行着八九个 IBM 自产软件，按照客户实际部署运行的方式设置，灌入由客户提供的“真实测试数据”，一轮测试完成下来需要一周，上 T 的数据。然后还需要一周的时间分析 log 来确定 defect 究竟由何引起。第三周发布一审判决，然后是各种上诉，推脱，喊冤，陷害。这个过程少则一周，多则论月。在经历过各种血雨腥风之后，发布终审判决和若干 PMR。然后等他们出补丁，没准儿是几个月后再进行下一轮了……

22

darktutu

OP

2019-01-31 08:21:00 +08:00

@ecloud 看我目前的经理，如果项目变大，就是你说的结果哈哈，所以特别好奇提出这个问题