项目开发流程
看一下这个项目开发流程图，当项目启动之后，产品的同事会先来一轮需求宣讲，告知大家本期大致做什么，产品的同事会整合各方的发言在完善一轮功能。
全部功能确定之后，会进入需求讨论，这个时候，开发会明确这一期需求中，到底要做哪些功能。也就进入了今天的正题，如何做开发设计。
为什么推荐写设计文档
我们先来回想一下最近的一次需求，下面几个问题，能回忆起几个：
哪些功能是相似的？相似功能有没有做通用处理？哪个功能实现起来有难度？最后是怎么解决困难点的？主业务流程是什么？有几条不同的业务流程？业务代码设计的可扩展性怎么样？新增了几个公共组件？用途分别是什么？老代码有改动吗？新老代码的兼容性是怎么处理的？有没有全新的、以前从没接触过的业务概念和体系，是如何应对全新业务的？有没有连带功能？连带功能的覆盖范围是哪些？......
产品视角的需求文档，需要在哪些地方做什么样的功能提供给用户。
开发视角的需求设计，不但要梳理清楚具体功能、功能所在的位置，还要考虑代码的质量。程序开发，不是单纯的代码堆砌。所以技术论坛了，我们看到很多优秀的怎么实现某类功能的文章。
设计文档是帮开发梳理业务功能，呈现优质的开发思维的载体。另外，当开发思路逐渐丰富，开发速度也就提上来了。
设计文档写什么？
上面的几个问题，也侧面的描述了设计文档中要写哪些内容。主要包括业务流程梳理，功能点梳理，功能的封装、通用、可扩展、兼容性设计，重点和难点归纳和实现方案，新业务概念和体系的应对方案，连带功能的覆盖范围总结。
下面我以最新一期接第三方支付的需求为例，讲讲这个耗时半个月的项目是怎么写前端设计文档的。
如何应对新的概念和体系
1、首先，梳理新概念中的新与旧，开发思维里按照这个维度将功能进行区分；
2、对于新的、没开发过的、不熟悉的概念和功能，独立划分出来，锁定具体哪方面没有开发经验，思考总结开发方案的同时，用查找资料、遵照成熟的开发设计的方式辅助设计开发方案。建议梳理开发的重点和难点，方便缩小开发难度的范围。
3、对于旧的、已经有开发经历的、熟悉的概念和功能，着重整理功能通用性、代码可扩展、代码可阅读等几个方面。
开发重点和难点
| 分类 | 内容 | 解决方案 |
| 难点 | 账户体系与权限的功能设计 | 详细设计见1.账户的两套设计方案 |
| 直接支付和第三方支付的差异设计 1、功能差异化处理 难点在于，虽然重新设计了账号体系，但是两种支付方式在功能上仍然有细小的差异化。 2、数据操作差异化 数据操作的难点在于，它既有在内部后台系统里录入的数据，也有从第三方过来的数据。 两种类型数据有三种按钮操作的情况： 1）没有数据权限类型； 2）内部后台支付数据类型； 3）第三方支付数据类型。 | 1、功能差异化处理 账户的信息下，增加支付方式的信息。依据支付方式区分功能差异。差异整理见2.系统的差异化功能整理 2、数据操作差异化 最重要是弄清楚数据权限，所以通过表格的方式将所有的按钮按照三种类型分类呈现，可以让后续的功能设计更加清晰。见3.后台系统不同数据类型按钮操作分类 功能设计上，采用物理隔离的方式，不同类型封装不同的组件。 | |
| 功能较多且分散 多且分散的功能开发，容易出现以下几种情况： 1）容易出现遗漏； 2）流程梳理和功能点梳理的困难度会高一些； 3）评估开发周期容易出现排期紧张的情况； 4）大量功能情况下，功能设计有可能不是最优。
| 1、相似性提炼 将相同或者相似功能进行提炼，封装为业务组件，同时通过表格罗列分组，这样只要引入的所有位置检查一遍，就不会有遗漏。
2、思维导图 以往操作流程基本是画主流程，帮助梳理主线功能，一些辅助的操作不会画进去。细致末节都是通过表格记录，但是功能太多，容易漏掉某个点。 所以这次尝试用用思维导图的方式，将细节点补充到思维导图中。 见4.思维导图 | |
| 批量导入操作 批量导入操作的难点在于数据量过大。 批量是为了解决超过100条数据操作的问题，所以批量导入的数据是不设限制的，这个时候后端可能一次性给过来几千条数据，前端一次性加载有一定概率导致页面卡顿。 | 1、数据量过大解决方案 参考了林三心大佬的「后端一次给你10万条数据，如何优雅展示，到底考察我什么?」
| |
| 重点 | 支付流程 | 1、流程图 流程图帮助梳理支付流程，见5.支付流程图 |
1.账户的两套设计方案
两套方案实现难度差不多。可以根据最终接口返回的数据详细程度，选择最终的方案。
我个人更倾向于方案一通过账号信息，设置账户的权限功能。
| 方案名称 | 优点 | 缺点 |
| 通过账号信息 1、如果接口返回了明显的标识可以区分当前用户的类型以及支付类型，可以直接使用； 2、如果没有，则前端按照用户的类型，手动添加支付类型标识。 | 功能集中，只需要处理一处地方就可以知道当前登录用户的支付方式。 | 1、有不确定性，如果没有明确标识，则需要手动添加； 2、改动权重过大，后续增加其他功能性标识的时候需要改动用户信息的公共功能。 |
| 需要判断的地方调用公共方法 封装一个判断支付方式的公共方法，需要进行支付类型判断的地方进行引入操作。 | 不必担心公共功能被修改的问题。 | 分散，只专注了下单业务，没有考虑系统全局。 |
2.系统的差异化功能整理
| 功能位置 | 功能描述 | 处理方案 |
| 订单列表 | 提交支付，根据支付类型不同，支付弹窗的内容不同 | 新增的第三方支付功能单独开发，根据当前用户的支付类型进行区分展示。 |
3.后台系统不同数据类型按钮操作分类
订单管理
| 数据类型 | 可操作按钮 | 备注 |
| 没有数据权限 | 详情、日志 |
|
| 内部后台支付数据 | 支付、退款 | |
| 第三方支付数据 | 支付 | 第三方支付的数据目前不支持在内部后台进行退款操作 |
4.思维导图
5.支付流程图
总结
将原本繁星点缀、星罗棋布的设计思维，改良为现在的纲领在前、繁星在后，优先想清楚重点和难点的卡点在哪以及解决方案，复杂流程结合琐碎细节的需求如何设计才能更优雅且不发生遗漏等。
将收获转化成知识进行传播，就是我写这篇文章的初衷。
