设计文档 - 也称为技术规范和实施手册，描述如何解决问题，是确保正确完成工作的最有用的工具。 其目的是迫使您仔细思考设计并收集其他人的反馈。 然后完善你的想法，同时在软件交付和交接的过程中，可以帮助别人更容易地理解之前的设计目的和想法。

内容： 1、什么是软件开发设计文档

创建并快速迭代——通过不断的思考、论证和缜密的思考来改进稳定文档的第一个版本

评审（可能有多轮）——集思广益，面对其他人的问题，收集其他人的反馈和意见，改进文档

实现和迭代——当发现编码实现与设计冲突或设计缺陷时，及时调整和更新文档

维护和学习——随着业务功能不断变化，文档应及时更新，避免误导后来接手或阅读的人。

摘要（任务的背景，如时间、地点、人物、背景、计划、替代方案等）

表结构以及它们之间的关系（ER图：实体关系图）

业务流程图、时序图（按照人操作的维度）

程序流程图、时序图（按照代码执行的维度）

接口约定（暴露的方法、api接口等）

其他（伪代码、类图、思维导图、泳道流程图、关于安全性、性能、边缘情况、成本效益的想法）

注释（补充说明和解释、引用材料）

审核状态

2. 为什么要写软件开发设计文档？ 3. 编写软件开发设计文档要注意什么？

文档工具不统一，不同群体和部门之间存在差异。 有些人甚至不知道文件是什么格式，无法打开它们。

过度抄袭需求文档，缺乏软件设计内容，不像软件设计文档

布局混乱，设计文档不遵循标准模板顺序，缺乏清晰的目录结构。

设计文档中图片过多，部分图片质量较差，缺少原文件。 比如EA工具缺少eapx文件，就会导致文档迭代需要全部重绘，久而久之，就会更加不愿意维护和更新文档。

没有统一的文档版本管理工具写文件的软件，缺乏追溯和统计管理能力。

数据库表结构设计风格杂乱不一致，字段没有中文描述（毕竟母语不是英语），主键和索引设计基本没有考虑。

程序流程基本比较简单，缺乏主线，无法描述核心算法和关键点（比如ATM怎么取款？有的只是描述[插卡->取款->取款卡]这还不够，还应该包括各种Verification、事务、并发、缓存等）

类图缺乏类之间的关系，有的直接使用英文函数名而不进行说明。

大多数序列图只描述与数据库的交互，缺乏业务流程和程序执行的序列图。

如果你不明白设计文档的含义，那么对于非常简单的任务需求就不需要编写设计文档。

缺乏对安全、性能、边界条件和成本效益的思考。 考虑不够全面，审查不严格。

文档编写者：架构设计师或功能开发人员

明确该文档的对象是谁：部门内的开发人员？ 合作伙伴实施者？ 外部开发人员？

设计先行：设计文档先写好再编码，这样可以大大避免后期返工，提高开发效率。

一图胜千言：尽可能用图片和文字清晰表达设计思想

统一绘图工具：需要支持导入导出，方便后续更新

统一文档模板：为了防止文档奇怪、布局不一致、阅读困难等问题。

确定托管形式：从安全（文档加密）、方便查看、版本管理等方面考虑，建议使用内部知识文档管理系统，类似wiki\git\svn的版本管理工具，或者内联网微盘

好的代码比设计文档更好：有时编写优雅的代码和注释比编写设计文档更好

版本迭代：在软件功能迭代过程中，经过多次迭代后，功能和设计可能会发生较大变化。 设计文档要及时更新，避免向人们传递错误的信息。

4.如何编写开发设计文档

1.推荐开源绘图工具：

图片取自官网

2.Word（设计文档模板，也可以使用wiki\confluence等团队工作区管理工具）

3.xMind（绘制思维导图）

4.Visio（绘图工具，目前未找到mac版本）

1.下一篇我会介绍如何使用draw.io画图（时序图、流程图、类图、ER图、架构图）

2.列出一些参考资料：

▶ 流程图：

▶ 时序图：

▶ 类图：

▶程序流程图#生命周期图

3.贴出预览图（示例写文件的软件，仅供参考）：