项目开发流程：
为什么要写功能设计文档？
写代码要比写文字容易很多，不写文档，别人问起某个功能当时为什么这样写的时候，可能一时想不起来。特别是时间越久的项目，项目代码里面的注释，时间长了，自己都忘记当时为什么要这么写。
有文档，当接手别人项目的时候，就可以直接看文档，不用一行一行去读代码。
设计文档还可以帮助开发梳理业务功能，考虑代码的质量，提高开发效率。
前端功能设计文档写什么？
简单一句话，让别人来看你的文档也知道怎么实现需求。
怎么写前端功能设计文档？
先整体，再细节，需求整体 - 页面 - 组件/模块这样的层次去组织设计方案。
完整执行一遍需求流程的模拟，这个需求涉及到的全部环节、状态与环境,
在设计页面和功能时, 把这个页面或者组件的全部功能列举清楚, 这些页面或组件又有什么样的状态变化和交互，同时评估开发的工作量。
前端技术设计文档模板
1 概述
1.1 需求背景
简单描述项目的背景和价值
1.2 前置概念
解释后面文档中需要用到的一些专有名词
2 相关文档
收集版本开发的相关文档，需求清单、原型、UI设计、后端接口设计文档、测试用例等相关信息
| 序号 | 标题 | 内容链接 | 相关人员 |
|---|---|---|---|
| 1 | 需求原型 | xxxx.com | 产品A |
3 项目排期
3.1 任务拆解
主要描述开发任务归属、预计工时
| 需求名称 | 模块名称 | 任务 | 排期（人/天） | 模块归属 |
|---|---|---|---|---|
| 模块1 | 0.5 | A | ||
| 模块2 | 1 | B | ||
| 合计人天 |
3.2 项目里程碑
| 事项 | 日期 | 备注 |
|---|---|---|
| 需求评审 | ||
| 技术评审 | ||
| 版本提测 | ||
| 版本发布 |
4 总体设计
4.1 开发规范
| 序号 | 名称 | 地址 |
|---|---|---|
| 1 | 前端开发规范 |
4.2 架构图
按需设计
5 模块详细设计
5.1页面设计
5.1.1 模块一 模块名称一级-二级
模块描述：有哪些页面，哪些功能
URL：页面访问地址，多个用表格列出（包括页面名称，页面地址，备注）
UI & 交互逻辑(UI拆分)：用图表示，页面跳转弹窗逻辑图、流程图、状态图（多个状态下的交互逻辑）
状态：业务环节的全部状态（如：上下架，启停用等）
请求逻辑：
后端接口设计文档
1、查询分页列表接口：接口URL
| API | 路径 | 请求字段说明 | 接口说明 |
|---|---|---|---|
| 分页列表 | /pageList |
请求方法：POST/GET
入参：
| 参数 | 说明 | 类型 | 是否必填 | 默认值 | 备注 |
|---|---|---|---|---|---|
| pageNo | 页码 | number | 是 | 1 |
返参：
业务逻辑：分点列出，相似功能做通用处理，新增的公共组件有什么用途，改动老代码兼容性处理，新增的业务逻辑，缺省情况处理
埋点逻辑：
伪代码：适当贴一些关键代码，兼容处理特殊说明截图，使用文字方便检索
5.2 组件设计
模块描述
UI & 交互逻辑
状态 / Props
业务逻辑
埋点逻辑
5.3 公共模块
模块描述
业务逻辑
6 技术分析 checklist
| 序号 | 技术分析自检查项 | 是否完成 |
|---|---|---|
| 1 | 本次改造对原有功能需求的影响范围，包括以前交互，视觉设计 | |
| 2 | 是否可提取出公用组件 | |
| 3 | 数据结构变更是否考虑老数据兼容 | |
| 4 | 是否影响移动端 | |
| 5 | 操作是否做了防重处理 | |
| 6 | 兼容性（浏览器、分辨率、主题） | |
| 7 | 团队 Code Review Checklist |
7 测试数据
测试地址、测试账号、测试数据。
8 测试重点
测试需要重点关注的部分，对现有业务的影响。
