一、背景

前端即便是小团队，偶然也是会冒出多人单干问题。

• 编码格调不能保障对立
• git 应用不标准，某些不标准的代码推送造成历史代码失落
• 新人对别人代码上下文不相熟改变产生 bug

等等。

问题的防止要求到集体是不牢靠的，扩散精力到琐碎如缩进格局的细节也会升高生产力。

因而，思考应用自动化加上流程改良的计划，无效拦挡问题。

二、指标

标准流程

• 产品、我的项目的代码都设成爱护分支，禁止 force push 等危险操作
• git 提交可控，如当抵触解决失误、无心笼罩多个文件，检查人员可能不便看进去，防止合入主分支
• 性能批改 commit 必须带上 jira id，不便开发日后看 git 历史理解上下文、QA 剖析

代码放弃优雅

• 编码格调对立

  如文件排列规定统一

• 减少可维护性、可读性

  如变量表意，没有大段无用代码，尽量应用新的稳固语法糖，缩小冗余代码

• 防止潜在 bug

   如相等判断应该应用全等符号，而不是仅仅比拟值

质量保证

防止低级谬误，如把编译不过、导致白屏的代码合并到主分支

保障单元测试笼罩的代码性能不被毁坏

三、流程

四：审核形式：Merge Request

代码合并到我的项目 / 产品主分支前肯定要通过 merge request 的形式进行合并。

1. 把所有我的项目 / 产品分支设置为爱护分支，能禁止 force push（🈲️）这种危险操作。
2. 能够增加一系列主动查看，让代码标准查看成为强制、常态、主动的。
3. 人造给 code review 提供方便
4. 对于高级继续集成计划，构建、实际的工夫老本很低

主动查看：流水线

把本地提交合并到近程骨干分支前，须要通过一系列查看。

为什么须要流水线

防止本地查看因为种种原因被跳过（如代码很急跳过查看，习惯不好不喜爱查看，环境配置不对导致本地查看不失效等等）

查看内容

查看不通过，如提交的批改新增了 lint 谬误，流水线会失败。

人工查看：Code Review

MR 流水线通过后，须要通过其他人确认没有看出问题。能力由有权限的人进行合并。

Review 根本规定

1. 严格遵循 MR/git/ 代码格调的标准
2. 不容许谬误应用 git 导致提他人的代码（比方一个非重命名提交几十个文件改变）
3. Reviewer 提出有潜在的 bug，作者要提交新的修复 commit 才通过 review

前置条件：自审

本人才是 MR 的最终负责人，防止谬误提交。

1. commit 是否只蕴含无效提交

   1. 不蕴含他人的提交

   2. 如本次 MR 集体只提交了 5 个 commit，就应该只有 5 个 commit

      如多出一个无用的 merge commit，一般批改逻辑不该有这样的提交

2. change 是不是都是合乎预期

   1. 能够很分明地看到文件改变数量，大量文件变动是不失常的
   2. 左侧变动导航能够分明看到改变了那些文件，是否蕴含本人未被动变动过的文件批改
3. 流水线跑过后再请人 review，防止来来回回浪费时间

这些都是一眼能扫出来的问题。

Code Review 利弊剖析

益处：

• 提前缩小问题
• 能够碰撞思维，让代码更加强壮优雅。

顾虑 Q &A：

• Q: 开发格调不一样，如果 reviewer 有集体爱好（如一个工夫转换工具叫做 DateUtil 还是 DateTransfromer），很难花工夫去探讨、迁就

  • A: 不要提集体爱好，次要按集体的倡议另外找工夫和所有人拉通，放在开发标准里。
  • A: 强烈的倡议能够提 gitlab issue，找工夫集中整顿 issue，列为技术债指定人一一解决
  • A: 对于没有写在标准文档里的，然而社区公认的不好实际，不予通过，如被废除的办法

• Q: review 他人代码会不会太消耗精力，看不出问题是否接受压力。

  • A: 对于相熟的代码，很快就晓得干了什么
  • A: 对于不相熟的代码，不明确的请对方阐明，能够减少本人对我的项目的根本理解。在工夫紧的状况下，能够不关怀逻辑，只查看一些准则问题。
  • A: reviewer 只是躲避危险，提出倡议。作者才是最终负责人。

• Q: 一个人负责的我的项目，且非新人、合作伙伴、实习生，合并前须要 code review 吗？

  • A: 合并到主分支里的代码须要，其余灵便变通。

五、提交 MR 步骤

如小明须要向产品分支 feature-AAA 奉献代码，对应 jira 工作 JIRA-1001

1. 基于最新 feature-AAA 分支 checkout 一个新的本地分支 xiaoming，更举荐以 jira 号命名 JIRA-1001。集体分支名不能和主产品、我的项目分支命名相似，其余如果没有标准看集体习惯。

   git checkout feature-AAA
   git pull --rebase
   git checkout -b JIRA-1001

2. 在本地分支 JIRA-1001 上提交批改。

3. push 到对应近程分支

   git push --set-upstream origin JIRA-1001

4. 命令行可主动提醒创立 merge-request 链接

   或点击 gitlab 网站上创立 merge request。留神选对【待合并分支】和【待合入的分支】

5. 点击流水线跑过后后立刻 merge 按钮，则跑过后会合并。默认近程分支会删除。

上述操作实现后，如果要在同一个本地分支上持续提交代码，确保在提 merge request 之前，本地代码和待合入的代码放弃同步。

git fetch origin feature-AAA（或罗唆 git fetch --all）git rebase origin feature-AAA 

如果有抵触，先在本地解决了再 push。防止反复提交、或提了 MR 后才发现有抵触，浪费时间。

MR 格局要求

1. 是否合并多个 commit 为一个

   1. 对于很小变动的提交（比方所有 MR 都做的同一件事件，抉择压缩所有 commit 到一个）。放弃主分支变更历史清晰。
   2. 每个 commit 做了独立的事件，不 squash

2. 对于性能批改代码，变更历史须要蕴含 jira id。

   如果压缩 commit：MR title 带 jira id

   不压缩：commit 须要带 jira id

   保障主分支代码历史有变更根据。

问题

• 提交 merge request 后，合并之前又有人提交了新的代码怎么办？

  点击 rebase 即可线上更新代码，如果没有抵触，则可持续流程

• 为什么同步了最新的代码提交 merge request，过了一会儿又发现有抵触？

  可能是其他人合入了与你的 MR 产生抵触的代码。

  此时把近程分支删除，更新本地代码，解决抵触后从新提交。

  // 把近程分支删除
  git push origin JIRA-1001 --delete
  
  // 更新本地代码
  git fetch origin feature-AAA（或罗唆 git fetch --all）git rebase origin feature-AAA

六、贴士💡

• 在本地 IDE 配置主动格式化代码，主动修复工具🔧

  配置保留时主动格式化。

  简略的谬误能够也能够主动修复。

• 性能代码提交后运行主动修复命令。如果有主动修复造成的更改，再提交一个修复的 commit。

七、更进一步的冀望

更多的补充查看

动态查看 / 代码扫描

• 如 sonar，可能发现更多问题。

功能性测试

高级功能测试，保障运行正确

作用：开发确保页面可拜访，至多能拜访首页（或默认页面），防止低级谬误（如页面拦挡逻辑写错导致我的项目白屏）

测试撰写：前端开发

环境保护人：前端开发，集成到前端流水线

老本：较小。要为功能测试做配置，至多要搭建一个含有根本 API 拜访的 mock server，须要破费一些工夫。

高级功能测试，保障前端性能

作用：从前端单方面保障所有根本稳固的页面交互正确，防止新代码合入改坏旧性能以及修复旧性能造成 QA 反复工作

测试撰写：QA 撰写本人保护的测试用例，前端开发撰写一些白盒用例

环境保护人：前端开发，集成到前端流水线

老本：较大。须要搭建自动化同步更新后端接口 + 人工 mock 数据合并的 mock server，要花费较多的工夫。保护起来能够变成开源我的项目。每个我的项目要独自筹备一些初始数据。

比较完善的功能测试，端到端

作用：还原实在的测试场景，测试稳固的重要性能，保障测试到的场景下所有链路性能失常。

比方测试某个页面时，能够期待几秒后截图，截图邮件发给 QA，能够定期检查，截图是否合乎预期。甚至能够留一个底图做像素比对，类似度低于肯定水平时才发告警邮件。

版本开发实现，提交测试后，修复性代码合并前应该通过功能测试。

测试撰写：QA 撰写本人保护的测试用例，前端开发撰写一些白盒用例

环境保护人：所有开发、运维。独自成一条流水线，不影响提测前代码合并。流水线失败也可能看到。

老本：很大。对于前端和测试只须要筹备本人的测试用例，对于前端所有的下层开发都要筹备一些初始数据，保障测试环境的稳固，运维须要筹备和重置测试环境，筹备流水线。每个我的项目要独自筹备一些初始数据。

可能存在的问题剖析

• 提测后，修复代码可能造成新的 bug

  解决方案：

  • 人工形式：

    提测后，相干分支除了通过流水线外，必须被其他人 review 批准后才可合并。

    review 新人（对我的项目齐全不熟）、合作伙伴、实习生的代码，除了基本准则，肯定查看明确代码逻辑。

  • 自动化的形式：跑功能测试后才可合并（期待将来搭建）

• 流水线有时比较慢，须要运维共事帮忙优化

  解决方案：

  • 优化 CI 配置，前置依赖下载给多个 job 应用。
  • 配置缓存，至多缩小反复下载依赖的工夫。

更好地造成闭环

• 流程可视化，如在办公室设立一个专用大屏（投影，或者电视挂在墙上），流水线失败会显示挂掉的 UI
• 主分支流水线失败及时告诉，用邮件、群机器人🤖️、扩音器播音的形式揭示对应提交人
• 如果有自动化功能测试，功能测试失败会主动发邮件给 QA