前端怎么做 Code Review？

[caisanli]

迫于团队（ 6 人）代码和技术参差不齐

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

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

也很难上 TS

目前想的方案是：

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

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

[dayeye2006199]

先上 linter ，再上单元测试，大 feature 附上设计文档，其他都好说

[GiantHard]

代码逻辑的 review：
1. 减少单个 merge request 代码量，例如控制在 500 行代码以内
2. 提供自测截图，录屏之类的东西
3. 提供修改代码的说明

代码风格的 review 交给 lint 工具来做，自动执行

[WildCat]

Lighthouse 跑分
Playwright 端到端测试

[EPr2hh6LADQWqRVH]

分割逻辑和 UI ， 逻辑不能涉及任何三大框架和"状态管理"

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

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

一份代码凑齐几个，谁也救不了

[caisanli]

@dayeye2006199 之前弄了套 Lint 规则 想着老项目改动太大 不用上 现在看来还是要弄上。

[caisanli]

@GiantHard 最近发现好几个同事写了几千行的代码 头疼

[caisanli]

@WildCat 学习去了

[caisanli]

@avastms 后台管理系统基本 UI 和逻辑全耦合在一起，稍微复杂点，一个页面就千行代码

[ericgui]

@caisanli lint 和项目改动没关系，只是对你代码的格式进行限制

[2i2Re2PLMaDnghL]

lint 你要嫌会产生一个巨大的 commit ，可以限制在只有 commit 涉及的代码强制 lint ，这样就能稍少痛的逐文件渐进地更新。

[caisanli]

@2i2Re2PLMaDnghL 对 我之前也这样想过 所以没让老项目修改 现在要加上 git hook 看看

[ruoxie]

vue2 可以用 https://github.com/vuejs/composition-api ，然后逻辑与 UI 分离
├── index.less
├── index.tsx
├── service.ts
├── useController.tsx
└── useModel.ts

[ChangJingli]

《 CODE REVIEW 中的几个提示》 https://coolshell.cn/articles/1302.html

[nzbin]

lint 工具只是提交前的审查，提交之后的代码是需要组长亲自审核把关的，vue 那代码也是一言难尽

[caisanli]

@ruoxie 哈哈哈谢老哥，这样会不会太细了

[caisanli]

@nzbin 我在想如何走这个“检查问题 - 提出问题 - 修复问题 - 复审问题”的流程，可以用上 GitLab 的 issue

[lgc653]

上 eslint ，也不用分那么多层，不同功能的方法定个命名规则就行了

[nzbin]

@caisanli 有点想复杂了，merge request 之后直接审查评论，然后让提交者修改就可以了

[AyaseEri]

很难，我觉得你得先让技术差的人提升一下水平。我司有些 git 只会 commit 、push 、pull 的人，在 husky 跑出错误后直接就懵逼，啥工具都不好使。

[caisanli]

@AyaseEri 的确难 我还是想折腾下

[AyaseEri]

@caisanli ESLint + Prettier 做风格管理，然后 Excel 表格做 Code Review 问题管理，重点还是问题登记与跟踪。

[parrotdance]

我觉得我们团队的做法不错, 可以参考一下:

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

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

坏处嘛...可能就是对书面表达能力有一定要求