一. 需求
1.1 评审
- 召集需求涉及到的UI、开发、产品、测试人员整理业务流程，同步信息，明确分工
- 明确需求目的，考虑当前需求设计是否可满足目的
- 整理流程中如果涉及的其他人员，则召集商讨
- 如需求设计上影响现有业务功能，应要求产品重新设计实现方案，然后重新评审
1.2 注意事项
- 业务流程同步：评审后重新梳理流程，存在疑问处及时找产品沟通
- 周边需求依赖：评审功能与依赖功能并行开发，由于前置需求未完成导致当前需求时间成本被压缩
- 埋点需求：提前与产品明确是否需要埋点
- 造数据：提前了解测试数据制造的困难程度，预估测试时间--->有些场景下的测试数据非常难造
- 并发量：后端机器是否能够承担新需求下的并发量，如果无法承担的话必须给出后续方案
- 自测：由于开发人员不予提供线上账号，因此自测也需要一名测试人员做线上回归测试
- 兼容范围：pc端需明确要兼容哪些浏览器，移动端需明确android与ios兼容版本以及哪些移动端浏览器
二. 开发
2.1 评审
2.1.1 原型图评审
- 向产品明确原型图在应用中所处位置以及入口的显示条件，确认原型图的正确性
2.1.2 设计稿评审
- 观察线上应用设计风格与当前设计稿风格是否一致(色调，字号，行高，对齐方式)是否一致
- 观察设计稿中哪些部分需要切图
- 判断设计稿中组件是否开发过，避免重复造轮子
2.1.3 技术实现评审
- 如存在不易实现的功能，第一时间与产品沟通其他降级的实现方案
2.1.4 排期
- 找到相关开发(前端，后端，app)商讨需求实现技术细节，明确产出接口格式时间与接口联调时间
2.2 代码管理
为防止合并代码时过多的代码冲突问题，建议使用分支时遵循以下标准- 每次push前先拉取线上分支代码
- 开发新功能或者修复bug时一定要基于线上代码分支创建新分支，每个分支只对应一个jira号或一个待修复的bug问题
- 分支名以f_(提交人)_(jira号)方式命名，对jira进行bug修复时使用f_(提交人)_fix_(bug内容)_(jira号)
- commit格式规则：每行message描述一个功能点，message格式为$(操作)：$(描述)，操作一般为add,del,upd分别代表新增、删除、更新三种操作
2.3 开发与调试
一般开发时不会从造轮子开始，项目中一般会有组件库供开发人员使用，但也会有一些老旧的项目中组件库版本较低，无法满足需求，
因此在开发前一定要对项目现有组件进行评估，确认是否需要重新开发组件，确保进度如期进行。
2.3.1 pc端
推荐优雅降级方式开发，先chrome，firefox，然后再针对兼容性较差的如ie等进行兼容处理
2.3.2 移动端
移动端页面兼容性相较于pc端较好，但需真机调试，为方便调试移动页面，这里推荐使用spy-debugger来让pc端做代理，具体使用
请查阅github文档。
2.4 自测
自测环节与环境数据关联很大，需要前后端共同完成，如果自测所需数据涉及范围较广，则需要找齐相关人员协助
