概要设计的必要性及写法

1.1.文档的重要性

很多小伙伴在需求、开发、测试阶段不注重文档，认为这耽误时间、画蛇添足。实际上文档对于软件行业是十分重要的。软件的定义：软件是包括程序、数据及其相关文档的完整集合。
从这个定义中我们能够体会到文档的重要性。很多小伙伴常说要对线上数据保持敬畏，对线上程序保持敬畏，同样的，我们也要对文档保持敬畏，千万不能轻视他。
往小里说，文档代表了传承与积淀。我们在抱怨前辈没有留下足够的文档、前辈文档不规范时，有没有想过通过自己的努力给后来者留下宝贵的积淀呢？赠人玫瑰，手留余香，写文档的过程也是思考的过程，将不明确的明确，将不清晰的清晰，将有争议的定论。
文人读书是道，武人练武是道，开发者在工作中也要追寻自己的道，把能做到的做好。为软件行业的规范化贡献自己的一份力量。

1.1.1.敏捷与文档

敏捷开发与文档是否冲突？CRM团队一周一版本，需求零碎化，是否还需要写文档？这里我们做下探讨。
敏捷宣言：
个体和互动 高于 流程和工具；
工作的软件 高于 详尽的文档；
客户合作 高于 合同谈判；
响应变化 高于 遵循计划；
敏捷宣言中的要义十分值得我们去理解，但是我们这里不做探讨。重点看下第二点，这也是一些小伙伴疑惑的地方。
实际上，敏捷想要表达的是，软件本身就能提供很多的信息，比如注释，包结构等，具备专业知识的同学一看就能一目了然。我们需要的是“刚好足够”的文档，一些细节的信息不一定需要通过文字图形等表达，代码自然能说明一切。
小伙伴们对于这一点的理解比较容易矫枉过正，对于“刚好足够”的理解过于简单。这也是值的我们深思的一点，我们的文档需要体现什么？然后才是去思考如何体现。

1.1.2.赶工与文档

项目周期短，我只有两天时间，晚上还要加班，要不要写文档？
换位思考一下，项目中的其他小伙伴能不能根据需求文档和你的代码注释十分清晰的理解需求的背景、实现方式、交互流程等。只要有必要，都需要写。
实际上，赶工是项目管理中即会增加资源消耗，也会增加风险的一种行为。有文档的指引能够帮助我们减少风险，同样也能减少由于返工、修复问题等消耗的资源。正所谓磨刀不误砍柴工，提供“刚好足够”的文档，有利于提高我们的开发质量。

1.2.文档的类型

在软件开发周期中，我们可能会接触到很多文档，例如：需求规格说明书、概要设计、详细设计、数据库设计、测试计划、测试说明、测试报告、部署方案、实施报告等。
每种文档的关注点不同，在敏捷开发中，实际上我们可能会对其中的某些文档进行合并、删减，由于我们接下来主要讨论的是概要设计，其他的我们也不展开讨论。这里借用一篇网上博文，可以窥探到这些文档的功能与常用结构。
https://www.jianshu.com/p/a7984927cfb9

1.3.概要设计的常用结构

在软件开发过程中，我们发现《概要设计》通常比较能满足“刚好足够”这个条件。
遇事不决先TODO，遇事不决总分总，遇事不决套模板。当我们不清楚设计文档应该怎么写时，我们可以先来了解设计问题可以怎么写。
概要设计文档中可以包含这些模块：
【目的】【背景】可以表明文档编写意图，指定预期的读者；可以帮助我们了解需求的背景。
【术语及缩略语】可以给文中提到的名词下定义，这里不光是指一些比较专业的名词，例如：核销。也可以是一些通用名词，在特定的场景下的特定意思，例如：逾期，在特定的文档中可以特指用户在最晚缴费日前未缴费。
【参考资料】列出有关的资料。
【总体结构】
【系统架构】
【基本处理流程】
【关键逻辑多方案】在概要设计中可以对关键逻辑设计多个方案，经过评审后确定一个方案，其他方案可以不删，体现思考过程、取舍过程。
【尚未解决的问题】
【接口设计】可以包括内部接口定义和外部接口依赖。
【数据库设计】
【非功能设计】
概要设计文档可以灵活的对这些涉及到的内容进行取舍，增对一些场景甚至可以增加条目，如【历史数据处理】、【数据迁移方案】等。千万不能像写八股文一样，也千万不要写成审查清单，这样文档的可读性反而下降了。

1.4.常用的图表

在上面提到的【系统架构】、【基本处理流程】等多处，我们可以利用图形来表达我们的思想。在作图时我们不能太随意，尽量遵守各种图形的一般表示方法，这样别人也更好理解。当然也可以从美观角度进行优化。

1.4.1.用例图

用例图主要用来描述角色以及角色与用例之间的连接关系。说明的是谁要使用系统，以及他们使用该系统可以做些什么。用例图包括这些元素：

关于每个元素的含义及用法，可以参考：
https://www.cnblogs.com/xiaolongbao-lzh/p/4590897.html

1.4.2.流程图

流程图主要用于展示过程步骤，大家对这个了解的也比较多。实际上流程图在需求文档中用的比较多，请善待愿意在需求文档中画流程图的产品，因为他们认真思考过。
开发同事也可以用流程图表示逻辑过程、逻辑步骤等。

1.4.3.泳道图

泳道图也叫活动图，其实就是在流程图的基础上，增加了两个维度。流程图关注流程，泳道图关注流程、阶段、对象。
三维的图形比较容易混乱，我们可以对其中一个维度进行降维。如舍弃阶段，或者舍弃对象。
这样可以比较清晰的表达思想。

1.4.4.ER图

ER图是实体-联系图，提供了表示实体类型（长方形）、属性（椭圆形）和联系（菱形）的方法。
关系有三种：1:1，1:N，M:N。
一个例子：

1.4.5.序列图

序列图主要用来更直观的表现各个对象交互的时间顺序，将体现的重点放在以时间为参照，各个对象发送、接收消息，处理消息，返回消息的时间流程顺序，也称为时序图。
有这些要素：

需要注意的是消息、异步消息的区别，异步消息想表达的是不关心返回值。

1.4.6.类图

类图在概要设计中画的比较少，核心逻辑、设计模式可以通过类图更清晰的表现。
一个例子：

1.4.7.架构图

我对这一块一知半解，其实并不懂，其他类型的图表有较为清晰的表达方式，架构图的表达方式比较灵活，用不同的软件画也有比较大的差异。期待了解的小伙伴能够进行指导。
一个例子：