V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
chaleaochexist
V2EX  ›  程序员

大组是如何分活,协同工作的?

  •  
  •   chaleaochexist · 2019-09-04 16:52:19 +08:00 · 2889 次点击
    这是一个创建于 1888 天前的主题,其中的信息可能已经有所发展或是发生改变。
    一开始
    小组后端就俩人.一个为主(楼主),一个打杂.
    现在项目扩大.
    将来可能要将近 10 个人.

    每个人的代码风格都不一样(python). 将来很容易乱套啊.领到的意思是, 不用分那么细.大家的活大家一起干.
    但是风格不统一,很糟糕啊 .
    举个例子.
    django drf 的 serializer 只有我一个人再用. viewset,也只有我一个人再用.
    其他人都是基于 apiView 在写.
    另外还有一部分人连 django orm 都不用. 直接裸 sql.
    目前组内规模 4 个后端, 本人不是领导.这事儿我不吱声,也没啥大事.
    可预见的将来,组内最懂 django 的应该还是我. 我不提,大家应该是意识不到这个问题.(我猜的)

    1. 如何分工,能把自己摘出去,自己代码自己维护?
    2. 如何统一风格?
    3. 三字真言?

    谢谢
    第 1 条附言  ·  2019-09-05 11:10:14 +08:00
    其实楼主在问两个问题.
    1. 技术问题,如何处理? -- 其实楼主已经有答案了, java 这类可能可以用编译器(Java 的接口泛型 Spining)约束.python 很难.
    2. 这是一个职场话题,楼主,现在应该咋做呢?管好自己就行了?
    24 条回复    2019-09-05 13:42:54 +08:00
    chaleaochexist
        1
    chaleaochexist  
    OP
       2019-09-04 16:52:44 +08:00
    另外,本人之前的工作经历也一直是几个人做,最多 3 个人,没有大组工作经历.
    chaleaochexist
        2
    chaleaochexist  
    OP
       2019-09-04 16:55:16 +08:00
    还有领导是真牛逼(褒义)

    前端出身, 现在是全栈, django 用的不熟, 自己手撸了一个阉割版除了他自己别人看不懂的 orm.
    还要很多 drf 提供的功能不用,自己手撸.
    撸的不好用啊...主要是...
    MMMMMMMMMMMMMMMM
        3
    MMMMMMMMMMMMMMMM  
       2019-09-04 16:56:07 +08:00   ❤️ 1
    大多公司都是模块化

    一人写 common,其他人拧螺丝

    各管各,尽量别动别人代码
    gz911122
        4
    gz911122  
       2019-09-04 16:57:21 +08:00   ❤️ 1
    我们是 java
    但是可以参考一下,我们组是做支付的
    基本两个人为一小组来负责 3~4 个服务

    代码风格之类的有插件来保证.
    依赖库之类的优先用公司通用的,特殊的在技术评审上来说明采用的原因和目的
    Hopetree
        5
    Hopetree  
       2019-09-04 16:58:31 +08:00
    django 也是按照 app 来划分吧,其实就是模块化,反正保证路由接口都是 OK 就行,谁写的谁负责改问题就不大
    gz911122
        6
    gz911122  
       2019-09-04 16:59:58 +08:00
    接楼上,我们组目前 13 个人..

    然后两个人左右为一小组(单元)的话正好还能相互 review,以及在有人请假的时候出问题不至于谁也不知道怎么办之类的
    chaleaochexist
        7
    chaleaochexist  
    OP
       2019-09-04 17:13:56 +08:00
    @gz911122 插件能保证的是编码风格,但是不能保证逻辑. 譬如,有人用 mybatis,有人直接 JDBC 裸 sql.
    gz911122
        8
    gz911122  
       2019-09-04 17:23:12 +08:00
    @chaleaochexist
    这种靠 code review 和技术评审了
    bobuick
        9
    bobuick  
       2019-09-04 17:25:33 +08:00
    换语言. 超过 10 人的 python 团队, 对人员素质要求变高很多.
    python 是个看视简单, 实际非常挑人的技术活
    azcvcza
        10
    azcvcza  
       2019-09-04 17:47:13 +08:00
    动态语言不都是要上 linter 来确保风格一致吗,
    规范之类的要领导发布,例如不能裸拼 SQL,页面怎么写,等等等等
    分工 的话,分模块吧,那块崩了就找谁,事先做好约定?
    cydleadingx
        11
    cydleadingx  
       2019-09-04 19:36:31 +08:00
    先讨论或者直接定义出一份 code style
    技术评审 /code review 搞起来
    必须 很多人 都 approve 了 才能 merge
    这种会导致项目进度 刚开始慢一些
    whywhywhy
        12
    whywhywhy  
       2019-09-04 19:41:31 +08:00 via Android
    我们的乙方估计就一两个开发,其他的实施兼二次开发。

    他们时不时就把对方代码覆盖。

    牛 X,于是苦了我们的数据。

    终于他们后面统一了。。。

    不知道为什么有的代码还是不见了。
    linZ
        13
    linZ  
       2019-09-04 19:52:35 +08:00
    @gz911122 code review 需要过逻辑么。。。那不是过起来要好久
    iPhoneXI
        14
    iPhoneXI  
       2019-09-04 19:59:48 +08:00
    python ?格式之类 black 一把梭,不准有异议,
    其他风格搞个内部规范,不在规范内的随便发挥
    xulolololololo
        15
    xulolololololo  
       2019-09-04 20:13:54 +08:00
    最好不用 django serializer 之类的吧,自由度受限,我现在规模 35 人左右的 py 后台开发团队,写一个通用的 baseview,其他人继承一下,这个 baseview 有通用的参数类型检验,和 jsonrespone 之类的方法,新来一个程序猿,熟悉一周业务开始干活,还是很快的
    xulolololololo
        16
    xulolololololo  
       2019-09-04 20:19:30 +08:00
    直接裸写 sql 的组员赶紧辞掉吧
    hmxxmh
        17
    hmxxmh  
       2019-09-04 20:30:12 +08:00 via Android
    @xulolololololo 这啥逻辑,裸写 sql 不用 orm 也有错。只要业务与数据分离就还好吧
    hmxxmh
        18
    hmxxmh  
       2019-09-04 20:32:35 +08:00 via Android
    我现在也遇到了你的问题,一个项目五个后段,一开始也没有设计数据库,基本上是先分模块,然后自己的模块需要的表自己建……,写完自己测,再与前端对接
    gz911122
        19
    gz911122  
       2019-09-04 21:18:18 +08:00
    @linZ 过啊

    很快的啊.因为项目很熟悉,再加上一般一个版本改动的文件也就几个到十几个之间
    Leigg
        20
    Leigg  
       2019-09-04 21:28:23 +08:00 via Android
    需要统一!这时候老大得有,要么你去提议做代码评审
    whusnoopy
        21
    whusnoopy  
       2019-09-05 08:33:13 +08:00
    Python 在项目大了或人多了后,管理起来是相对麻烦点,这时候比较考验人的素质,大家都有协同意识,或愿意接受统一,那就是提前沟通一下确定好标准,否则靠工具撑死也就保持个代码风格,逻辑风格啥的完全管不住
    DoctorCat
        22
    DoctorCat  
       2019-09-05 10:59:01 +08:00
    业务背景没有的情况下,姑且认为你们每个人可以独立负责一个服务,各自约定各自的接口,先文档化(要顾及性能要求、调用限制等详细的 API 设计约束条件),然后照着文档各自开发各自的。

    技术栈需要约定,不然队友离职后,挖出的坑,你们老板(或交接人)会很抓狂。建议设立 CodeReview 流程,push 到仓库的代码必须是经过他人 review 过的。

    非要总结出三字,那就是:责(各自负责各自的服务)、约(约定好技术规范和业务接口设计标准)、审(做代码审查)
    DoctorCat
        23
    DoctorCat  
       2019-09-05 11:02:14 +08:00
    btw:软件工程本质上还是人的问题,不太可能达到完美状态,利用合理的工具和约定,尽量减少技术负债与沟通成本
    starsriver
        24
    starsriver  
       2019-09-05 13:42:54 +08:00 via Android
    接口丰富一下,统一成插件标准,各写各的。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5525 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 27ms · UTC 08:29 · PVG 16:29 · LAX 00:29 · JFK 03:29
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.