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

重构老项目,团队里多是新人,对业务不了解,有什么好的方式?

  •  
  •   unregister · 76 天前 · 2257 次点击
    这是一个创建于 76 天前的主题,其中的信息可能已经有所发展或是发生改变。

    老项目业务有较多的专业词汇,新项目对代码质量高,同时 dev 要作为产品经理的角色。code review 是让 leader code reivew 。代码越来越复杂了,作为新员工,个人觉得快速熟悉业务的方式是一起参加 code review ,但是这样是否会占用比较多的时间呢?现在还没有强制的单元测试覆盖率的要求,不免有些担心

    第 1 条附言  ·  76 天前
    感谢各位的回复,总结下,在不熟悉业务的情况下,一起参与 code reivew 有助于对项目的理解。
    standchan
        1
    standchan  
       76 天前   ❤️ 1
    先开一些前期的沟通培训会议,把项目做什么的,从系统层面上介绍一下,再从模块层面介绍一下各个模块的输入输出。沟通的细节就到专业的词汇讲解吧。让新人对于项目有整体上的认识是非常重要的。另外项目当中肯定也有一些坑还留着,也要挖掘出来。
    code review 是重构老项目必须做的,有一种误区是感觉写代码的时间算工作时间,review 时间就是浪费了。如果没有好好 review 代码,再加上你是重构,后期出问题加上加班维护,反而得不偿失。
    新项目可以把单元测试覆盖率正好上马,一开始可以从项目中的重点模块开始,覆盖率的要求也不要定的太高,一步一步慢慢来。
    standchan
        2
    standchan  
       76 天前   ❤️ 1
    补充:code review 一开始可以大家一起参加几次,这样有助于形成比较固定的代码风格。后期就是模块的 developer 和 onwer 结对进行 review ,这样也兼顾了效率。
    wangritian
        3
    wangritian  
       76 天前
    我个人觉得 code review 对增加业务逻辑的理解效率极低,建议是产品经理首先对项目全貌做一下概括介绍,然后一个个模块分批迭代,例如你们决定先重写订单模块,就先充分了解订单需求和对应数据库结构(没必要看老代码),团队设计好代码架构,单独开发订单服务,然后在老项目中把订单接口从本地运行改为转发请求到新服务,直到所有服务迭代完毕
    chenqh
        4
    chenqh  
       76 天前   ❤️ 1
    能跑就不要动..

    更何况没有单元测试,没有集成测试,重构只是自找苦吃.
    cvbnt
        5
    cvbnt  
       76 天前 via Android
    最快的方法是整出一份项目使用说明书,比如电商平台的商品上架流程,新人自己作为用户操作过一遍就大概知道哪些功能模块是干什么的,针对操作过的模块进行修改
    huage
        6
    huage  
       76 天前   ❤️ 1
    先用 1-2 周的时间熟悉业务,不搞开发。老人讲业务逻辑、数据逻辑,新人边学边讲,每个人都要讲,都要评价。
    zxc12300123
        7
    zxc12300123  
       76 天前 via iPhone
    辦公室政治?盲猜空降了領導洗了一波人
    unregister
        8
    unregister  
    OP
       76 天前
    @standchan 好细节,感谢。
    @wangritian 开发兼顾 pm 的角色,目前还没有对业务形成自己的理解
    @chenqh 有自动化测试,单元测试也有但是不强制
    unregister
        9
    unregister  
    OP
       76 天前
    @cvbnt 电商比较常见,我们这个领域比较专业
    @huage 你们是这样实践的吗?感觉还挺少见的,最后都变成走形式,哈哈
    ydpro
        10
    ydpro  
       76 天前
    重写
    anerevol
        11
    anerevol  
       76 天前   ❤️ 1
    自顶向下说说为什么要这样组织代码,每个模块核心职责是啥。 然后有针对性去对一个模块有更深入的了解。 单纯的 codereview 可以简单的看成是自底向上,在没有 context 的情况下对为什么要这么写,写得好不好很多时候很难去评判的。
    hefish
        12
    hefish  
       76 天前
    全部裁了,把老人招回来。
    unregister
        13
    unregister  
    OP
       76 天前
    @anerevol 是的,感觉也需要这样的一套方法或者方法论,code reivew 的话也有局限性。
    starlion
        14
    starlion  
       76 天前   ❤️ 1
    codeview 是一种方法,但是对于新人来说,有点慢,也不易理解,
    1. 可以先让熟悉项目的人或架构讲解下项目的整体流程,各个模块之间关系,画出关系图,先有个整体了解和印象,在解释下一些专业词汇
    2. 代码细节流程的话,那就要问负责这块的老开发和产品,其实最重要是曾经遇到哪些坑,咋避坑
    3. 最快其实是上手写代码,当然从简单模块开始,这个时候可以一起 codeview ,给配个导师 。看你这应该没有培训新人的项目
    4. 最后就是测试,单元测试,集成测试等
    暂时想到这些
    DeWjjj
        15
    DeWjjj  
       76 天前
    解决屎山的方法只有,抛掉一块删掉做一下微服务。
    akira
        16
    akira  
       76 天前
    老项目重构的时候 顺便补一下 设计文档啊 ,测试用例啊啥的 也是挺好的
    unregister
        17
    unregister  
    OP
       76 天前
    @starlion 现在就是老的开发忙于做分派给自己的一些 story ,具体他做了啥不是特别清楚。另一方面整个架构之前讲过了,但时间太久有些忘了,需要再看一下,专业词汇没人讲,都是自己一个个查字典,知识库,自己体会。
    @DeWjjj 实际我们是重写。
    @akira 是的呢,good idea ,我们老的项目有很多测试用例,但是不一定适合新的项目
    jjshare123
        18
    jjshare123  
       76 天前
    我最近也在思考这个问题,我的结论是有工具能够把项目,把前前后后参与的人,前因后果能够非常方便、高效、不额外浪费大量精力地记录下来。
    我已经有模糊的想法,感觉可以形成一个强有力的产品,不过可能帮不上你这次的忙。有兴趣的朋友可以一起讨论。

    你这次的话,我个人建议是先梳理需求。然后按照需求,大概的进行 code review ,颗粒度到文件、方法名、API 即可。
    w3cll
        19
    w3cll  
       76 天前
    防御式编程
    chendl111
        20
    chendl111  
       76 天前
    @chenqh #4 重构就有 OKR 了,晋升/跳槽利器
    StephenHe
        21
    StephenHe  
       76 天前
    做下依赖升级,在运行个几年。除非换框架语言,新人重构感觉也不一定写的更好
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2692 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 27ms · UTC 15:03 · PVG 23:03 · LAX 08:03 · JFK 11:03
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.