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

前端怎么做 Code Review?

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

    迫于团队( 6 人)代码和技术参差不齐

    代码风格和代码逻辑没法看

    目前项目大部分基于 Vue2 (需要兼容 IE10

    也很难上 TS

    目前想的方案是:

    • ESLint
    • 把有问题的代码贴出来

    正好公司要实行绩效,我有打分权,是不是可以实行一下手段。

    22 条回复    2022-01-03 23:42:53 +08:00
    dayeye2006199
        1
    dayeye2006199  
       142 天前   ❤️ 1
    先上 linter ,再上单元测试,大 feature 附上设计文档,其他都好说
    GiantHard
        2
    GiantHard  
       142 天前 via Android
    代码逻辑的 review:
    1. 减少单个 merge request 代码量,例如控制在 500 行代码以内
    2. 提供自测截图,录屏之类的东西
    3. 提供修改代码的说明

    代码风格的 review 交给 lint 工具来做,自动执行
    WildCat
        3
    WildCat  
       142 天前   ❤️ 2
    Lighthouse 跑分
    Playwright 端到端测试
    EPr2hh6LADQWqRVH
        4
    EPr2hh6LADQWqRVH  
       141 天前 via Android
    分割逻辑和 UI , 逻辑不能涉及任何三大框架和"状态管理"

    UI 越薄越好,责任到人,爱咋咋地

    前端几座大山,
    不会面向对象,jsx ,尤雨溪,airbnb 规则

    一份代码凑齐几个,谁也救不了
    caisanli
        5
    caisanli  
    OP
       141 天前
    @dayeye2006199 之前弄了套 Lint 规则 想着老项目改动太大 不用上 现在看来还是要弄上。
    caisanli
        6
    caisanli  
    OP
       141 天前
    @GiantHard 最近发现好几个同事写了几千行的代码 头疼
    caisanli
        7
    caisanli  
    OP
       141 天前
    @WildCat 学习去了
    caisanli
        8
    caisanli  
    OP
       141 天前
    @avastms 后台管理系统基本 UI 和逻辑全耦合在一起,稍微复杂点,一个页面就千行代码
    ericgui
        9
    ericgui  
       141 天前
    @caisanli lint 和项目改动没关系,只是对你代码的格式进行限制
    2i2Re2PLMaDnghL
        10
    2i2Re2PLMaDnghL  
       141 天前
    lint 你要嫌会产生一个巨大的 commit ,可以限制在只有 commit 涉及的代码强制 lint ,这样就能稍少痛的逐文件渐进地更新。
    caisanli
        11
    caisanli  
    OP
       141 天前 via iPhone
    @2i2Re2PLMaDnghL 对 我之前也这样想过 所以没让老项目修改 现在要加上 git hook 看看
    ruoxie
        12
    ruoxie  
       140 天前
    vue2 可以用 https://github.com/vuejs/composition-api ,然后逻辑与 UI 分离
    ├── index.less
    ├── index.tsx
    ├── service.ts
    ├── useController.tsx
    └── useModel.ts
    ChangJingli
        13
    ChangJingli  
       140 天前
    《 CODE REVIEW 中的几个提示》 https://coolshell.cn/articles/1302.html
    nzbin
        14
    nzbin  
       139 天前
    lint 工具只是提交前的审查,提交之后的代码是需要组长亲自审核把关的,vue 那代码也是一言难尽
    caisanli
        15
    caisanli  
    OP
       139 天前
    @ruoxie 哈哈哈谢老哥,这样会不会太细了
    caisanli
        16
    caisanli  
    OP
       139 天前
    @nzbin 我在想如何走这个“检查问题 - 提出问题 - 修复问题 - 复审问题”的流程,可以用上 GitLab 的 issue
    lgc653
        17
    lgc653  
       139 天前
    上 eslint ,也不用分那么多层,不同功能的方法定个命名规则就行了
    nzbin
        18
    nzbin  
       139 天前
    @caisanli 有点想复杂了,merge request 之后直接审查评论,然后让提交者修改就可以了
    AyaseEri
        19
    AyaseEri  
       139 天前
    很难,我觉得你得先让技术差的人提升一下水平。我司有些 git 只会 commit 、push 、pull 的人,在 husky 跑出错误后直接就懵逼,啥工具都不好使。
    caisanli
        20
    caisanli  
    OP
       139 天前 via iPhone
    @AyaseEri 的确难 我还是想折腾下
    AyaseEri
        21
    AyaseEri  
       139 天前
    @caisanli ESLint + Prettier 做风格管理,然后 Excel 表格做 Code Review 问题管理,重点还是问题登记与跟踪。
    parrotdance
        22
    parrotdance  
       139 天前
    我觉得我们团队的做法不错, 可以参考一下:

    1. 每个 mr 至少对应一个 issue.
    2. 编码之前开一个空 mr, 在其中简述问题原因 /需求拆解 /解决思路, 组员之间 review 并讨论.
    3. 编码完成后编辑 mr 内容, 加入测试部分内容(截图或视频), 确认改动是有效的.
    4. review 代码改动.

    这样做的好处在于别人 review 的时候大概知道你这个改动想干什么, 再去看代码脑子里能够有个总体脉络, 另外换个人来看 mr 里描述的思路和测试结果也容易发现考虑不周的地方.

    坏处嘛...可能就是对书面表达能力有一定要求
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   4355 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 27ms · UTC 02:08 · PVG 10:08 · LAX 19:08 · JFK 22:08
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.