这是一个创建于 667 天前的主题，其中的信息可能已经有所发展或是发生改变。
大家好，真心好奇团队开发是怎样进行的
我是公司唯一前端，虽然与后端，设计有合作，但前端一套都是我自己，这里也可以引申为唯一后端
我好奇的点：
- 一个程序，团队是怎么分配任务的？按功能分配？按模块，逻辑分配？
- 如果同事开发有一些不太优雅的地方，是抱着少管闲事的态度？
- 如果我要用 xx 第三方依赖库，我需要申请吗？
- 是不是要经常处理 git 冲突？
一个人开发久了，没有限制，决定权大，说实话我想象不出来团队的开发的样子
希望各位可以赐教
 |
1
god7d 2023-01-18 12:55:09 +08:00  2
找一家流程正规的公司就全懂了，不过我也自己浅薄的经验帮助 op
“一个程序，团队是怎么分配任务的？按功能分配？按模块，逻辑分配？” 不同公司的分配逻辑不同，跟他们的团队规模、业务内容和行业有关。 “如果同事开发有一些不太优雅的地方，是抱着少管闲事的态度？” 如果不是 leader ，这些不优雅的代码又不影响自己，当然是假装没看见 “如果我要用 xx 第三方依赖库，我需要申请吗？“ 是的，一定要跟 leader 沟通，因为引入第三方依赖是影响整个项目的。 ”是不是要经常处理 git 冲突？“ 任务分配的合理并不需要太频繁处理冲突，即便是处理冲突，也不会出现大面积冲突的情况，后者一般都是项目架构、任务分配方式和时间等造成的。 |
 |
2
lneoi 2023-01-18 13:43:24 +08:00
让公司招人给你辅助, 就有合作机会了
|
 |
3
enchilada2020 2023-01-18 13:52:08 +08:00 via Android 1
羡慕啊~~我反而想问 如果你遇到自己搞不定的需求了 身边又没有大佬可以请教 该怎么办
|
 |
4
hhjswf 2023-01-18 14:04:25 +08:00 via Android
@enchilada2020 直接说，做不了
|
 |
6
GeruzoniAnsasu 2023-01-18 14:06:08 +08:00 2
> 一个程序，团队是怎么分配任务的？按功能分配？按模块，逻辑分配？
产品首先要划清楚 story 的边界，然后 story 由开发自行分配。但一般一个 story 的前端 /后端是一整个任务，会由一个人来完成 > 不优雅 经验资格最老的人会进行 review ，指导实现方式和框架，新人写不来就交换一下任务 > 三方库 开发内部自行讨论，reviewer/maintainer 同意就可以用。 > git 冲突 一个研发周期快结束的时候，80%的工作就是处理冲突，使 git workflow 能继续下去 |
|
7
GeruzoniAnsasu 2023-01-18 14:07:24 +08:00
代码质量的下限是 maintainer/reviewer 的容忍度下限。 但这点跟产品质量无关。
|
 |
8
for8ever 2023-01-18 14:08:02 +08:00
还是一个人好啊
|
|
9
GeruzoniAnsasu 2023-01-18 14:08:04 +08:00
|
 |
10
awesomes 2023-01-18 14:12:04 +08:00 3
回答一下我司的，任务从项目经理下来，给到产品，产品进行任务宣讲然后画出原型和文档，任务给到技术负责人，然后技术负责人将前后端任务分别下发到各自的组长（公司前端有多个小组，每组 4-6 人，不同小组负责不同的项目，分别有小组长）接下来小组长将整个大的任务分解成 N 个小任务，再根据截止日和每个组员的自身情况将任务分发下去，确保在截止日前能够交付。最终每个组员会提 mr ，小组长会大致审核一遍代码和功能，没问题就合进去即可，最终交付之前需要前后端一起做一次评审，再交由测试，测试说没问题了再上线。
关于第三方依赖库的使用不需要申请，但是组长会检查一下是否能用，但是基本功能主要组件库都能实现，用到特殊的第三方依赖并不多。 是否经常处理 git 冲突？很少，因为组长在分配任务的时候会有一定的策略，尽量避免协同开发的时候会涉及到公共的修改。即便真有涉及，也会分出来先后顺序。 对于 review 的话并不绝对，组长会对 mr 进行大致的审查，尤其是实习生或者新入职的组员，对于技术不错的组员一般只做功能验证即可。 关于按什么来分配任务得看当前的任务情况了，如果有多个模块的可能就是按模块，如果是一个模块很大的一个功能，那么就会所有人一起来做这个大功能中的每一小块，所以理论上是按照工作量来分配的，当然也会考虑到上面说的冲突的问题。 |
 |
11
morty0 2023-01-18 14:20:55 +08:00
需求评审->技术评审->任务拆分->协议评审->开发->联调->测试->验收->上线
|
 |
12
kensoz OP |
|
13
kensoz OP |
|
14
kensoz OP |
 |
15
lifesimple 2023-01-18 15:37:12 +08:00
1. 一般都是按功能模块分，比如你去做 pageA ，他去搞 pageB ，如果只有一个 page ，那大概按模块再细分，基本每个人做的东西不会有耦合相关阻塞
2. 能跑就行 少管闲事 3. 一般不需要吧 4. 很少，因为分任务的时候基本都是各做各的 |
 |
16
fuchish112 2023-01-18 16:37:54 +08:00
#11 是标准的流程，但实际中往往是很难的，比如说需求，一开始是这样，后面又那样，改来改去的，烦
|
 |
17
RealJacob 2023-01-18 17:15:38 +08:00
1. 不一定，看公司和团队的习惯，以及具体的项目。例如一个做后台系统的团队，那大概率一个人一直 maintain 一个项目的 bug 和迭代，但如果是个做 c 端活动的团队，那肯定是有啥活直接分配。对于已经成型的项目，有的是一个人一直负责一个项目 or 模块，有的是分配不同项目模块的需求，每次可能做的不一样。对于从 0 到 1 的项目，需要多人协作的，那就由组长分配。
2. 少管闲事，如果有 code review 那可以讨论，如果是已经线上跑的东西，只要不是太过分（影响性能 or 有明显 bug ）都尽量不去纠结优雅性，毕竟很多时候排期紧的情况下，很多人不会太注重代码的优雅。 3. 我们这里不需要，但取决于你是否是这个项目的负责人，如不是还是汇报下比较好 4. 如果是功能复杂同时开发人数多，迭代快的，那处理冲突是必然的 |
 |
18
haoyc 2023-01-18 17:24:17 +08:00
规范流程和效率是把双刃剑。
职场的一大原则：尽量不要做 OKR 以外的事情 |
Select Language