迫于团队( 6 人)代码和技术参差不齐
代码风格和代码逻辑没法看
目前项目大部分基于 Vue2 (需要兼容 IE10
也很难上 TS
目前想的方案是:
正好公司要实行绩效,我有打分权,是不是可以实行一下手段。
1
dayeye2006199 2022-01-01 06:06:52 +08:00 1
先上 linter ,再上单元测试,大 feature 附上设计文档,其他都好说
|
2
GiantHard 2022-01-01 09:06:37 +08:00 via Android
代码逻辑的 review:
1. 减少单个 merge request 代码量,例如控制在 500 行代码以内 2. 提供自测截图,录屏之类的东西 3. 提供修改代码的说明 代码风格的 review 交给 lint 工具来做,自动执行 |
3
WildCat 2022-01-01 09:13:37 +08:00 2
Lighthouse 跑分
Playwright 端到端测试 |
4
EPr2hh6LADQWqRVH 2022-01-01 10:55:29 +08:00 via Android
分割逻辑和 UI , 逻辑不能涉及任何三大框架和"状态管理"
UI 越薄越好,责任到人,爱咋咋地 前端几座大山, 不会面向对象,jsx ,尤雨溪,airbnb 规则 一份代码凑齐几个,谁也救不了 |
5
caisanli OP @dayeye2006199 之前弄了套 Lint 规则 想着老项目改动太大 不用上 现在看来还是要弄上。
|
10
2i2Re2PLMaDnghL 2022-01-02 05:59:36 +08:00
lint 你要嫌会产生一个巨大的 commit ,可以限制在只有 commit 涉及的代码强制 lint ,这样就能稍少痛的逐文件渐进地更新。
|
11
caisanli OP @2i2Re2PLMaDnghL 对 我之前也这样想过 所以没让老项目修改 现在要加上 git hook 看看
|
12
ruoxie 2022-01-02 18:47:51 +08:00
vue2 可以用 https://github.com/vuejs/composition-api ,然后逻辑与 UI 分离
├── index.less ├── index.tsx ├── service.ts ├── useController.tsx └── useModel.ts |
13
ChangJingli 2022-01-02 21:26:14 +08:00
《 CODE REVIEW 中的几个提示》 https://coolshell.cn/articles/1302.html
|
14
nzbin 2022-01-03 11:20:58 +08:00
lint 工具只是提交前的审查,提交之后的代码是需要组长亲自审核把关的,vue 那代码也是一言难尽
|
16
caisanli OP @nzbin 我在想如何走这个“检查问题 - 提出问题 - 修复问题 - 复审问题”的流程,可以用上 GitLab 的 issue
|
17
lgc653 2022-01-03 14:04:54 +08:00
上 eslint ,也不用分那么多层,不同功能的方法定个命名规则就行了
|
19
AyaseEri 2022-01-03 17:17:23 +08:00
很难,我觉得你得先让技术差的人提升一下水平。我司有些 git 只会 commit 、push 、pull 的人,在 husky 跑出错误后直接就懵逼,啥工具都不好使。
|
21
AyaseEri 2022-01-03 22:41:44 +08:00
@caisanli ESLint + Prettier 做风格管理,然后 Excel 表格做 Code Review 问题管理,重点还是问题登记与跟踪。
|
22
parrotdance 2022-01-03 23:42:53 +08:00
我觉得我们团队的做法不错, 可以参考一下:
1. 每个 mr 至少对应一个 issue. 2. 编码之前开一个空 mr, 在其中简述问题原因 /需求拆解 /解决思路, 组员之间 review 并讨论. 3. 编码完成后编辑 mr 内容, 加入测试部分内容(截图或视频), 确认改动是有效的. 4. review 代码改动. 这样做的好处在于别人 review 的时候大概知道你这个改动想干什么, 再去看代码脑子里能够有个总体脉络, 另外换个人来看 mr 里描述的思路和测试结果也容易发现考虑不周的地方. 坏处嘛...可能就是对书面表达能力有一定要求 |