标签：概述 sql alt 数据库 决策 实现 细节 源文件 模块
互联网公司，技术侧，写文档有没有必要？有必要。
至少要写总体设计文档，详细设计文档。
可能是没时间，可能是不会写，可能是不愿意写。
本文试图分享一些经验，解决“不会写”的问题。
总设和详设都应该包含的部分：
（1） 需求：一般以产品的语言描述，这一块可以拷贝产品需求文档中的story list部分；
（2） 名词解释（可选）：非相关领域内的同学需要看到文档需要提前了解的一些概念性质的东西；
（3） 设计目标：又分为功能目标和性能目标，功能目标一般是对产品需求的技术描述，性能目标是根据产品给出的数据对性能进行的评估。一般来说，新服务必须要有性能目标一项，性能目标可能会影响设计方案。
除了都应该包含的部分，总体设计一般还包含：
（1） 系统架构：一般来说会有个简单的架构图，并配以文字对架构进行简要说明；
（2） 模块简介：架构图中如果有很多模块，需要对各个模块的功能进行简要介绍；
（3） 设计与折衷：设计与折衷是总体设计中最重要的部分；
（4） 潜在风险（可选）；
输出总体设计的时候，很多方案还是不确定的，故总体设计重点在“方案折衷”，方案需要在设计评审会议上确认。
总体设计评审完毕之后，此时应该是所有方案都确认了，需要输出各模块的详细设计。
详细设计重点在“详细”，需要包含：
（1） 总体设计结论汇总（可选）：总体设计上达成一致的结论有个简要概述，说明详设是对这些结论的实现；
（2） 交互流程：简要的交互可用文字说明，复杂的交互建议使用流程图，交互图或其他图形进行说明；
（3） 数据库设计：这个是应该放在总设还是详设呢？
（4） 接口细节：输入什么参数，输出什么参数，根据接口前端、后端、APP、QA就能够并行做编码实现了；
（5） 其他细节：例如公式等；
理论上输出了详细设计之后，无论谁拿到了这个详设文档，都是能够完成该项目的。
（1） 大系统或复杂流程，其架构图或者流程图会非常大，经常比A4纸或word的一页大很多，此时不宜在word中直接贴图形，贴了也看不清，建议将图放在wiki上，文档中直接贴链接；
（2） 一定要保存viso或者其他图形的源文件，否则今后改动起来要重画，代价可想而知；
（1） 设计与折衷是总设中最重要的内容，总设评审中，主要就是讨论这些折衷的优劣；
（2） 评审过后，不但要邮件周知结论，还要在总设中进行更新，说明最终决定使用了哪种方案，为什么使用这种方案；根据自己的经验，接手别人的模块、项目，拿到代码和文档，设计方案对我来说完全是个谜！！！
（3） 有时候因为排期或者其他原因，不一定采用了最优的设计方案，此时更应该在总设中记录决策的过程与原因；
（4） 最后，设计折衷是一个很好的自我辩解的机会：因为项目进度，或者历史遗留问题，我不得不采取了一个这样的设计，不要再骂我了。
性能目标是新模块文档必不可少的一部分，很多项目对性能影响较大的话，也必须撰写性能目标，性能一般来说可能包含以下部分：
（1） 日平均请求：一般来自产品人员的评估；
（2） 平均QPS：日平均请求 除以 4w秒得出，为什么是4w秒呢，24小时化为86400秒，取用户活跃时间为白天算，除2得4w秒；
（3） 峰值QPS：一般可以以QPS的2~4倍计算；
画外音：详见《架构，如何进行容量设计？》。
互联网公司，产品迭代快，可能很多公司没有“文档”一说。但其实，写好文档，对系统和项目未来的维护是非常有帮助的。
画外音：文档清楚，开发阶段变化小；未来迭代成本小。
架构师之路-分享可落地技术
《回表查询？索引覆盖？| 1分钟系列》新出炉
《优化工具，迅猛定位低效SQL | 1分钟系列》
《数据库允许空值(null)是悲剧的开始 | 1分钟系列》
《两类非常隐蔽的全表扫描 | 1分钟系列》
你们公司写设计文档么？
标签：概述 sql alt 数据库 决策 实现 细节 源文件 模块
原文地址：https://blog.51cto.com/jyjstack/2548566
