前端开发流程

一. 需求

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 自测

自测环节与环境数据关联很大，须要先后端共同完成，若是自测所需数据涉及范围较广，则须要找齐相关人员协助