背景
开发的人员越来越多，各个人员之间对其他人的需求及对应的实现都不是特别了解。
如果要接手一个老的项目，那么需要从头开始捋顺整个流程，费时费力。
而且就算项目是自己写的，也可能因为历史悠久，而不太记得当时是怎么想的，为什么那么去做。
所以，在做每个需求的过程中，我们增加一个设计文档环节。让这个文档来承载，来记录针对这个需求的方方面面。
主要内容
应该包含的内容有：
- 背景：做需求是基于什么背景的，大概率PRD上有，但最后希望能提炼成自己理解的话
- 目的：做这个需求的目的，大概率PRD上有，但最后希望能提炼成自己理解的话
- 调研：写方案设计前的准备工作，如果是大需要，在其他地方已经写了，可以只附上对应的链接。
- 方案设计：侧重于某个东西应该怎么去做，会用到什么，可能会存在什么问题以及对应的解决，有必要的话，需要具体到某个模块。针对大型需求，需要单独开辟文档。
- 测试：影响范围，需要测试点
- 上线：侧重上线步骤，比如依赖服务端和B端的上线，还有新老版本兼容
一些说明
Q1：在哪个环节写这个文档？
A：需求评审完成可以完全的部分，明确的任务人再完成后面的设计文档工作。
Q2: 文档放在哪里？
A：放到confluence里，并且在代码里同时增加产品文档链接和设计文档链接。
Q3：文档怎么分类
A：
第一级：项目名 比如 tutor-web-mobile 第二级：一级路由，其他目录（存放一些小的，但是涉及面广的需求） 第三级：较大型需求，比如有超过三个页面及以上的
命名加日期 比如 xxx 2020-08-25
Q4：迭代需求如何放
A：
之前没有目录新增目录 注明上一版需求地址
Q5: 写完谁去看
A：
写完先发群里 根据需要组织技术评审
大型需求需要前期调研和以及对应的设计文档，可以在别处写，这边附上对应的链接即可。
Q6: 设计方案变动该怎么做
A：优先改设计方案，改完后再在群里发一下，再根据需要组织一次评审，主要是看影响的范围，比如需求变动比较大。
Q7：其他目录下的文档放哪里
A：针对其他目录的文档，链接优先放到代码段部分，如果太多，放到git log里
最后
先尝试一段时间看看具体效果如何。