开发过程规范

一.需求评审规范

产品需求评审

1. 准备阶段【评审前一天】
   产品提供开发需求文档，应包含项目背景、原型图、涉及功能模块、详细需求等
   研发如果首次开发需求文档中涉及的模块，需在预发/线上熟悉涉及模块流程

2. 评审阶段【评审中】
   需求合理性（业务逻辑关系）
   前后端实现方式（技术逻辑关系）
   实现难点（潜在技术风险），是否需要调研，是否需要其他团队（如中台）协助

3. 评审结果
   输出评审阶段结论（合理性，难点或者协作项）

UI评审

1. 准备阶段 【评审前一天】
   设计稿给到开发
   将设计稿中的内容与需求文档进行比对，是否符合需求文档内容
   设计稿中交互逻辑是否清晰
   设计稿跟公共组件是否冲突（例如iviz图标有自己的样式，需要定制样式）
   关注中英文切换样式的兼容

2. 评审阶段【评审中】
   就准备阶段发现的问题跟设计沟通

3. 评审结果
   设计输出更新，前端记录变更备忘

技术评审

1. 准备阶段【评审前一天】
   后端技术文档
   接口完整度，是否包含所有业务接口
   接口数据完整度，是否能支撑前端字段以及逻辑

2. 评审阶段【评审中】
   就准备阶段发现的问题跟云端沟通
   云端业务的延展性和拓展性（讨论）

3. 评审结果
   输出结论备忘

二. 开发过程风险管理规范

Note: 尽量把问题前置在评审阶段，降低开发过程风险；任何研发对开发过程可能存在的风险，应及时通报具体的影响范围寻求对应解决思路和方案；

开发进度

【排期】尽量颗粒化细粒度需求进行开发工时评估，控制最大单位不超过1 day，最小单位hour （举个🌰：排期demo）
【开发】拆解的任务根据进度每天录入项目中心
【周会】对本周计划进度回顾，以及后续计划的进度预估或者风险预评

开发过程问题

【技术问题】前期对需求把握不充分或者技术实现难度
寻求替代方案
寻求TL/跨团队成员支撑
是否需要适当增加时间或者研发
结果上报TL/Owner

【需求问题】开发过程发现的需求逻辑冲突
及时跟产品、云端梳理出对应解决方式
有延时风险的及时上报TL/Owner

【工时问题】评审时认为的小修改涉及到了多个组件业务
及时跟技术负责人、云端、产品、测试同步问题，判断该改动是否会有延期风险，或者是否对测试造成额外工作量
有延时风险的及时上报TL/Owner

【Block点】硬件/云端/基础部门等依赖第三方
是否可以重新调整开发顺序
是否可以mock数据、虚拟设备
有延时风险的及时上报TL/Owner

开发进度风险

【进度与排期】任何产生延期风险的问题，第一时间寻求对应方案
开发延期（与技术负责人、业务、产品、虚线负责人）
依赖延期（与技术负责人、依赖方、业务、产品、虚线负责人）

【多迭代冲突】
迭代优先级调整导致研发调整的，重新评估排期或者延后
依赖调整导致研发调整的，根据优先级调整开发

【需求变更】
是否需要重新评审评估
是否会导致重复开发
对原计划的影响风险

三. 上线checklist 规范

1）在【海外租住迭代/国内租住迭代】- 【各迭代】中新增一条记录
2）迭代文件夹命名为：Q + 迭代名
3）checklist中包含内容如下：
发布区域（国区/欧区/美区）
发布操作步骤，包括检查代码是否合并master、确认前端网关、确认网关全局配置、确认多语言是否配置、发布的项目、上线后回归与合并master发布责任人
每个应用的回退版本
每个应用需要发布的前端接口，接口功能
修改网关的话需要做个备份，方便回滚
如果需要发布线上灰度，需要提前检查网关，是否会对线上造成影响
建议在路由网关描述中，加入迭代版本，方便多个迭代同时进行时，找到自己迭代更新过的网关

四. 复盘标准规范

什么情况下需要复盘？

一般为结果不佳、结果超出预期、过程中较大问题或者有价值有亮点时我们认为需要做迭代复盘；复盘的目的是将好的总结下来发扬光大，结果不佳的总结经验避免重蹈覆辙。

复盘需要准备？

上线checklist文档
复盘文档
项目背景
期望达到的效果，是否已达成
哪些做法可以保持
有哪些做法不妥/有价值，不妥/有价值的原因是什么
针对不妥/有价值行为，有哪些改进/推广方法

总结反思

查看此次复盘中存在的问题是否已出现过
多次出现的问题是否已得到改善
将复盘会议输出归档

五. code review 规范

为什么需要code review

保证代码风格统一，命名规范，检查代码逻辑，不存在多层嵌套死循环等问题

code review 时间节点

上线前一周内

参与人员

主审人、开发者、组内成员

评审内容

组件命名规范：驼峰命名
组件构成：配置文件，UI文件，处理数据文件，样式文件。
配置文件中存放表单配置、表格配置
UI文件中存放Page DOM，不涉及任何逻辑
处理数据文件中存放页面数据，页面逻辑
代码中是否存在多层嵌套，例如 多个if嵌套，多个循环嵌套，多个三目运算符嵌套
代码中是否存在死循环
代码中是否存在魔法值，例如 status = 1/2/3/4/5
代码中多个相同常量是否抽到constant.ts中定义

总结反思

cord review结束后将会议内容总结为文档，文档内容包括：主审人、错误解决前/解决后代码截图，自行优化的代码截图
列出需要优化的点
评审后一周内，将评审需要优化的点优化完（主审人监督优化完成进度）
本次迭代评审之前，确认上个迭代提出的问题是否完成优化

六. git分支规范

分支类型：

feature/版本号 - 开发 （不能用于线上发布）
hotfix/版本号.bugName - 线上bug修复
release/版本号 - 部署
master
版本号必须必须是迭代代号，不能自己单独命名

保护分支：

保护分支设置：只有Maintainer角色才能合并代码，并且不能直接推代码上保护分支
release/*
master

正常开发流程

1.从master切出 feature/v版本号进行开发
2.部署使用 release/v版本号
3.上线后将 release/v版本号 合并到master 并打tag，tag使用版本号
4.合并好master后删除对应feature分支

多版本迭代并行流程

遵循正常开发流程，多版本使用灰度发布

紧急修复线上bug

1.从对应分支切出hotfix/v版本号.bugName 修复发布
2.发布完后合并master
3.删除本hotfix分支