整体流程：需求单阶段 ——> 需求评审 ——> 需求排期（技术方案设计）——> ui 开发——>联调——>发布测试环境——>跟测——> 测试通过（CR）——>发布外网——> 外网验证

整体流程

1.需求单阶段

自己看需求单，设计稿，明确疑问点和重点

2.需求评审

和开发、产品、设计等相关人员一起进行需求评审

3.需求排期

需求排期，技术方案设计 ——> 这个是重点

4.ui 开发

前端 ui 先行（可以自己 mock 一下数据，这时候还没有接口）

注：如果这时候已经有接口文档了，那么也可以直接按照接口文档来设计前端的功能和组件逻辑！

一般来说接口文档后端设计完了之后还要前后端一起进行一个评审，看看前端是否能够接受！或者有没有一些不合理需要改动的地方！

注：如果这时候有一些 UI 交互不明确的地方，可以单独拉产品去对一下 ——> 前端 ui 明晰的常见注意事项

比如常见的：

（1）tab 下面的框是否支持整体左右滑动（要用 swiper 实现）

（2）tab栏是否支持左右滑动（数量超过一屏），只要需要滑动的就需要单独出 ui

（3）背景图，图标，和描述文案等是走后台配置工具还是前端用配置的形式写成常量？

（4）有一些部分是否为动态的：比如进度条

（5）icon 区域这一整个 part 如果数量超过了多少行，怎么展示（固定行数，左右滑动/上下滑动；不固定行数，全部展示出来），排列 icon 怎么排列（一行一行排列，还是一列一列排列）

（6）有哪些需求并没有把ui详细画出来？ 需要进行补充

（7）有哪些部分是静态页面的，可以直接走公司的静态配置，或者页面配置？前端就不需要进行开发了

（8）是否涉及一些上报，埋点？

比如可以这样说：@产品今天上午11点方便一起对一下需求细节吗，有些交互需要跟你确认下

注：开发过程中想要提交 mr 给导师看更改，就向仓库的 smaster分支 提交 mr，这样新增的和修改的就一目了然了，而且不用真的去合并，因为合master没有权限，就只是去 diff 一下修改的内容

5.联调

和后端进行联调（根据后端接口设计和接口文档）

注意：这里后端可以先给jce等设计，前端根据这个设计开发

联调的时候后端先把接口发布测试，前端先在本地调，调好了之后再发测试，然后让后台和产品先试用一下！

总之不管是测试还是正式环境都是后端先发布，前端再发布

注意：bingo 给的经验：前端交互没有做好的情况下，如果之前的协议已经定好了入参出参

可以通 postman 来模拟联调

也就是说如果后端做的快，前端做的慢，那就先让后台自测即可

如果前端做的快后端做得慢，就催接口，先一个一个联调，或者先拿到 jce 文件（接口文档）之后优先完善好前端的业务逻辑

6.发布测试环境

发布测试（更改需求单状态为转体验，或者转测试）

从需求分支合入uat（test）分支，提mr

更改需求单：

7.跟测

测试人员入测（跟测）

8.测试通过

（1）测试同意合流

（2）code review

可以向 master 分支提交一个 mr，申请合入master分支

在这个过程中找相关人员进行 cr，添加评论

注意：提mr进行cr之前必须要处理的常见问题：

a.删除本地调试用的代码和本地用的注释（和业务无关的都删掉）

b.jsx种没有进行逻辑判断不要加不必要的{}

c.如果jsx组件只有一个根元素不要加没有必要的<></>

d.开发环境时候注释的代码，一定要记得打开

5.还有一些常见编码规范，放在下面：

https://www.yuque.com/u37834985/lgziyw/wuo7dtguc2pfigep

注意：在 cr 改完代码之后，因为这里不走测试了，所以一定要保证自己改的是对的，不然会增加测试的负担！

主要检查：1.改完之后必须重新启动项目，看是否能启动 2.改完之后必须本地跑起来看是否符合预期

3.改完之后本地跑的时候多点一点相关的功能 4.在该项目本文件夹范围内，搜索改动的相关变量有没有哪些影响的相关点，有相关的都要去处理相关的代码，一个变量可能影响的范围不仅是本组件，子组件也很有可能！

10.发布外网

正式合入master分支

注意：发布外网要等后端先发，前端再发

注意：从需求分支提 mr 到master分支（注意不要从uat分支提，因为 uat 可能还有别人不想发布的新的代码）

然后有的项目是合并到master分支就自动构建，有的项目是打 tag 才自动构建

例如：

电商管理后台 项目使用 OrangeCI 进行自动化构建和部署：

• 测试环境: UAT 分支推送 → 自动构建 → 自动部署
• 生产环境: Tag 创建 → 自动构建 → 自动部署

生产环境通过创建 Git Tag 触发发布：

• 确保代码已合并到 master 分支
• 在工蜂平台创建 Tag，命名规则：vYYYYMMDDXX

11.外网验证（继续跟测）

各方关系：对于前端所处位置的理解

产品提出需求，需求单和UI稿

对UI稿和需求单进行熟悉，大概明确需求

和产品明确其想要的效果和需求，开发设计实现方案和评估技术可行性（在开发过程中也会）——> 若存在问题则需要和产品定一些兼容或者兜底方案 ——> 进一步确认需求，可能会涉及改动

和产品确认交互细节和边界情况，方便 UI 开发的进行

组内进行排期评估 和 重难点技术方案明确

和后端对接实现方案（如有特殊需要注意的依赖关系的地方），定联调时间

进行接口约束对接，联调，测试接口可行性和前端实现合理性和业务逻辑完善

转体验，产品提出问题，弥补对需求单理解不充分或者错误的问题

转测试，功能性遗漏或者错误的地方，边界极端情况UI问题或者报错，兼容性或性能在实现上的个别情况考虑不周的问题