V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
kensoz
V2EX  ›  职场话题

真心请教团队开发的日常是怎样的

  •  1
     
  •   kensoz · 2023-01-18 12:46:45 +08:00 · 3684 次点击
    这是一个创建于 436 天前的主题,其中的信息可能已经有所发展或是发生改变。

    大家好,真心好奇团队开发是怎样进行的
    我是公司唯一前端,虽然与后端,设计有合作,但前端一套都是我自己,这里也可以引申为唯一后端

    我好奇的点:

    • 一个程序,团队是怎么分配任务的?按功能分配?按模块,逻辑分配?
    • 如果同事开发有一些不太优雅的地方,是抱着少管闲事的态度?
    • 如果我要用 xx 第三方依赖库,我需要申请吗?
    • 是不是要经常处理 git 冲突?

    一个人开发久了,没有限制,决定权大,说实话我想象不出来团队的开发的样子
    希望各位可以赐教

    18 条回复    2023-01-18 17:24:17 +08:00
    god7d
        1
    god7d  
       2023-01-18 12:55:09 +08:00   ❤️ 2
    找一家流程正规的公司就全懂了,不过我也自己浅薄的经验帮助 op

    “一个程序,团队是怎么分配任务的?按功能分配?按模块,逻辑分配?”
    不同公司的分配逻辑不同,跟他们的团队规模、业务内容和行业有关。

    “如果同事开发有一些不太优雅的地方,是抱着少管闲事的态度?”
    如果不是 leader ,这些不优雅的代码又不影响自己,当然是假装没看见

    “如果我要用 xx 第三方依赖库,我需要申请吗?“
    是的,一定要跟 leader 沟通,因为引入第三方依赖是影响整个项目的。

    ”是不是要经常处理 git 冲突?“
    任务分配的合理并不需要太频繁处理冲突,即便是处理冲突,也不会出现大面积冲突的情况,后者一般都是项目架构、任务分配方式和时间等造成的。
    lneoi
        2
    lneoi  
       2023-01-18 13:43:24 +08:00
    让公司招人给你辅助, 就有合作机会了
    enchilada2020
        3
    enchilada2020  
       2023-01-18 13:52:08 +08:00 via Android   ❤️ 1
    羡慕啊~~我反而想问 如果你遇到自己搞不定的需求了 身边又没有大佬可以请教 该怎么办
    hhjswf
        4
    hhjswf  
       2023-01-18 14:04:25 +08:00 via Android
    @enchilada2020 直接说,做不了
    tool2d
        5
    tool2d  
       2023-01-18 14:06:02 +08:00
    @hhjswf 程序员怎么可能说做不了,这不算变相说自己技术不行。

    只会说最近手头有点紧。
    GeruzoniAnsasu
        6
    GeruzoniAnsasu  
       2023-01-18 14:06:08 +08:00   ❤️ 2
    > 一个程序,团队是怎么分配任务的?按功能分配?按模块,逻辑分配?
    产品首先要划清楚 story 的边界,然后 story 由开发自行分配。但一般一个 story 的前端 /后端是一整个任务,会由一个人来完成

    > 不优雅
    经验资格最老的人会进行 review ,指导实现方式和框架,新人写不来就交换一下任务

    > 三方库
    开发内部自行讨论,reviewer/maintainer 同意就可以用。

    > git 冲突
    一个研发周期快结束的时候,80%的工作就是处理冲突,使 git workflow 能继续下去
    GeruzoniAnsasu
        7
    GeruzoniAnsasu  
       2023-01-18 14:07:24 +08:00
    代码质量的下限是 maintainer/reviewer 的容忍度下限。 但这点跟产品质量无关。
    for8ever
        8
    for8ever  
       2023-01-18 14:08:02 +08:00
    还是一个人好啊
    GeruzoniAnsasu
        9
    GeruzoniAnsasu  
       2023-01-18 14:08:04 +08:00
    @GeruzoniAnsasu #7

    代码质量的 **上限** 是 maintainer/reviewer 的容忍度 下限。
    awesomes
        10
    awesomes  
       2023-01-18 14:12:04 +08:00   ❤️ 3
    回答一下我司的,任务从项目经理下来,给到产品,产品进行任务宣讲然后画出原型和文档,任务给到技术负责人,然后技术负责人将前后端任务分别下发到各自的组长(公司前端有多个小组,每组 4-6 人,不同小组负责不同的项目,分别有小组长)接下来小组长将整个大的任务分解成 N 个小任务,再根据截止日和每个组员的自身情况将任务分发下去,确保在截止日前能够交付。最终每个组员会提 mr ,小组长会大致审核一遍代码和功能,没问题就合进去即可,最终交付之前需要前后端一起做一次评审,再交由测试,测试说没问题了再上线。

    关于第三方依赖库的使用不需要申请,但是组长会检查一下是否能用,但是基本功能主要组件库都能实现,用到特殊的第三方依赖并不多。

    是否经常处理 git 冲突?很少,因为组长在分配任务的时候会有一定的策略,尽量避免协同开发的时候会涉及到公共的修改。即便真有涉及,也会分出来先后顺序。

    对于 review 的话并不绝对,组长会对 mr 进行大致的审查,尤其是实习生或者新入职的组员,对于技术不错的组员一般只做功能验证即可。

    关于按什么来分配任务得看当前的任务情况了,如果有多个模块的可能就是按模块,如果是一个模块很大的一个功能,那么就会所有人一起来做这个大功能中的每一小块,所以理论上是按照工作量来分配的,当然也会考虑到上面说的冲突的问题。
    morty0
        11
    morty0  
       2023-01-18 14:20:55 +08:00
    需求评审->技术评审->任务拆分->协议评审->开发->联调->测试->验收->上线
    kensoz
        12
    kensoz  
    OP
       2023-01-18 14:26:01 +08:00
    @god7d
    @awesomes
    感谢老哥们的详细回答,十分受教
    这个第三方库真是,一个人开发都是看到好的就直接用,没想到团队开发还有这些步骤
    还有 git ,果然是和设计,策略等密不可分的
    学习了
    kensoz
        13
    kensoz  
    OP
       2023-01-18 14:27:28 +08:00
    @GeruzoniAnsasu
    感谢,原来如此
    虽然团队开发步骤多了,但是也确实更规范,学习了
    kensoz
        14
    kensoz  
    OP
       2023-01-18 14:30:20 +08:00
    @enchilada2020
    这个一般都是想办法做,而且我这个也没有什么高大上的东西
    比较老实,真搞不定的就只能说搞不定。。。不过这种情况就发生过 2 次
    办法都是各个地方搜,问,比如在 v2 问🤣
    lifesimple
        15
    lifesimple  
       2023-01-18 15:37:12 +08:00
    1. 一般都是按功能模块分,比如你去做 pageA ,他去搞 pageB ,如果只有一个 page ,那大概按模块再细分,基本每个人做的东西不会有耦合相关阻塞
    2. 能跑就行 少管闲事
    3. 一般不需要吧
    4. 很少,因为分任务的时候基本都是各做各的
    fuchish112
        16
    fuchish112  
       2023-01-18 16:37:54 +08:00
    #11 是标准的流程,但实际中往往是很难的,比如说需求,一开始是这样,后面又那样,改来改去的,烦
    RealJacob
        17
    RealJacob  
       2023-01-18 17:15:38 +08:00
    1. 不一定,看公司和团队的习惯,以及具体的项目。例如一个做后台系统的团队,那大概率一个人一直 maintain 一个项目的 bug 和迭代,但如果是个做 c 端活动的团队,那肯定是有啥活直接分配。对于已经成型的项目,有的是一个人一直负责一个项目 or 模块,有的是分配不同项目模块的需求,每次可能做的不一样。对于从 0 到 1 的项目,需要多人协作的,那就由组长分配。
    2. 少管闲事,如果有 code review 那可以讨论,如果是已经线上跑的东西,只要不是太过分(影响性能 or 有明显 bug )都尽量不去纠结优雅性,毕竟很多时候排期紧的情况下,很多人不会太注重代码的优雅。
    3. 我们这里不需要,但取决于你是否是这个项目的负责人,如不是还是汇报下比较好
    4. 如果是功能复杂同时开发人数多,迭代快的,那处理冲突是必然的
    haoyc
        18
    haoyc  
       2023-01-18 17:24:17 +08:00
    规范流程和效率是把双刃剑。
    职场的一大原则:尽量不要做 OKR 以外的事情
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2580 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 15:38 · PVG 23:38 · LAX 08:38 · JFK 11:38
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.