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

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

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

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

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

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

    前端出身, 现在是全栈, django 用的不熟, 自己手撸了一个阉割版除了他自己别人看不懂的 orm.
    还要很多 drf 提供的功能不用,自己手撸.
    撸的不好用啊...主要是...
        3
    MMMMMMMMMMMMMMMM   73 天前   ♥ 1
    大多公司都是模块化

    一人写 common,其他人拧螺丝

    各管各,尽量别动别人代码
        4
    gz911122   73 天前   ♥ 1
    我们是 java
    但是可以参考一下,我们组是做支付的
    基本两个人为一小组来负责 3~4 个服务

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

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

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

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

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

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

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

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

    非要总结出三字,那就是:责(各自负责各自的服务)、约(约定好技术规范和业务接口设计标准)、审(做代码审查)
        23
    DoctorCat   73 天前
    btw:软件工程本质上还是人的问题,不太可能达到完美状态,利用合理的工具和约定,尽量减少技术负债与沟通成本
        24
    starsriver   73 天前 via Android
    接口丰富一下,统一成插件标准,各写各的。
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2217 人在线   最高记录 5043   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.3 · 26ms · UTC 07:49 · PVG 15:49 · LAX 23:49 · JFK 02:49
    ♥ Do have faith in what you're doing.