技术设计文档模版
# 01.技术设计文档模版
# 01.整体概述介绍
# 1.1 项目背景
通过简要的语言描述项目背景以及要达成的业务目标。
当前做这个项目的背景是什么样的，为什么要做它。做这个业务的目标是什么样的，用简单的话语描述一下业务背景。
# 1.2 遇到问题
做这个技术设计是为了解决什么问题？
遇到问题----->排查问题----->解决问题----->反思后问题收获
# 1.3 基础概念介绍
需求背后技术的一些概念，如果有必要，用简单的言语描述一下基础概念。
- 比如对于日志上报库，简单说下日志查询，日志重试，文件分区等一些基础概念。
- 比如通用缓存存储库，简单说下目前常见缓存方式，有缺点，效率，主要解决什么问题。
# 1.4 设计目标
需求的背后往往会带来技术的重构/优化，或者单纯的完成需求，如果有必要，需要从技术角度给出方案设计的目标
- 比如对于图片下载需求，需要完成相关的功能，那么设计目标主要有完成异步下载、存储、缓存设计、图片解码、渲染等功能。
- 比如对于优化需求，目标可以是达到一个什么效果？可以是帧率的、Crash率的、卡顿的等。
- 比如对于重构需求，目标可以是加强扩展、解决问题、提升效率等。
# 1.5 产生收益分析
做这个主要是为了什么，是提高产品体验，还是造轮子复用，还是提高开发效率。
收益点是什么？产品和技术在这块都可以说出各自的收益是什么，一定要具体！尤其是产品的收益点，因为绝大数的领导关注的是产品收益，技术是偏下游的！
# 02.核心技术点
# 2.1 技术点梳理
技术点有哪些？把一些关键点罗列出来，把一个很大方案细分成多个关键节点，这样开发或者别人熟悉都会容易理解……
比如针对音视频聊天？关键技术点是TCP通信，悬浮窗，呼叫铃声和震动，权限申请，来电和去电技术设计等，尽可能把绝大多数的技术点拆分开……
比如针对通用视频播放器？如何屏蔽ijk，exo，原生等不同内核播放器api差异？视频view如何高度定制？如何和业务解耦合？如何处理横竖屏切换等？
# 2.2 困难点说明
有哪些难点，如果有就写出来。并且罗列一下这些困难点需要的技术调研，是否有阻塞性？
举一个例子，针对音视频聊天如何保证TCP及时性，如何弱网提示，如何做悬浮窗，进程杀死如何发消息，如何做View到Activity的转场动画？提前暴露出一些问题……
# 03.业务场景梳理
# 3.1 业务梳理点
这里需要梳理一些核心业务场景case，要较为详细地描述出业务的流程。简而言之，就是让人能快速理解技术背后的业务交互逻辑！
举一个例子，音视频通话的业务场景有：来电，去电，小窗悬浮，铃声和震动，还有和其他音视频播放器逻辑冲突场景等等！叙说业务场景点的时候，可以多用流程图！
# 3.2 核心逻辑说明
针对一些核心的业务，需要分析该场景的核心逻辑是什么？不仅仅要有文字描述清楚，而且还要用流程图展现出来。
举一个例子，核心点有来电，首先是笔给App打电话发送tcp，App收到消息后响应，然后开始聊天，然后经过主动或者被动挂断结束流程。
# 04.方案设计思路
# 4.1 技术调研分析
针对某些业务开发，刚开始还不确定技术实现细节。这个时候需要技术调研，如果没有则该项可以不写！
调研前的问题或业务是怎么分析的，如何确定技术方向的选型，自己的一些思索都可以写下来。
调研中是否遇到什么问题，有哪些可选取的东西，是否有技术难点，技术方案是否成熟都记录下来。
调研后一定要有个结果，哪怕没能具体实践，那也要说出自己的结论。比如调研Android手机双开App最后很难实现，那也要说出做了那些尝试。
# 4.2 方案对比论述
有时候，针对一个业务需求，可以用不同方案实现。你就要设计出有理有据的方案，这样技术的维度就会越来越高。
总结出了一个 3C 方案设计法，也就是每次做事的时候都至少设计 3 个方案，然后选择最优的 1 个或者几个方案去执行。
举一个例子：悬浮窗和大屏之前动画，是用补间动画，还是用属性动画，还是用转场动画？
那么这几种动画是否都可以实现，针对当前业务哪一种方式更好一些，为什么，这个时候技术方案多维度对比，那么就对技术更熟悉了！
# 4.3 总体设计思路
设计的初衷：概要描述方案设计的思考，可以是为了扩展性的考虑，可以是提升性能
关键技术点的思考：描述关键技术选型的思考，比如要解耦，业内解耦方案能有router、SPI等，讲清楚选择的思考
技术上的折中/取舍：在做技术设计的时候，往往要的很多，但时间有限，那么这个需要讲一下折中与取舍，以及接下来的规划、计划
# 05.方案基础设计
方案设计是技术文档的最核心部分，主要包括了整体架构和功能设计，这里需要体现。
功能设计包含但不限于以下几个部分：逻辑流程图、接口设计图、与外部的模块间依赖关系。
# 5.1 整体架构图
整体架构的组成需要有一张完成的架构设计图，描述清楚具体的分层以及层与层之间的关系
比如传统的开发会分为三层，展示层、逻辑层、数据层
- 展示层的设计：视图的构成、视图间的耦合关系、具体的交互逻辑
- 逻辑层的设计：支撑展示层所需要的数据、从数据层获取数据的加工、业务相关逻辑（比如轮询服务）
- 数据层的设计：数据的获取方式以及存储方式，文件、数据库、本地、网络
# 5.2 UML设计图
如果有需要，比较复杂的技术或者业务场景，可以描绘出UML模型图。
针对比较独立的功能模块，如果有必要，可以简单描述每一个类是做什么的？让其他人看着可以一目了然！
# 5.3 关键流程图
设计中的最复杂、最关键的逻辑需要画出流程图，实在画不出的流程图需要用语言描述清楚。
关键流程需要有逻辑流程图，帮助其他同学理解功能的关键节点逻辑。这块强烈建议使用思维导图表达更加直观！
# 5.4 接口设计图
通过UML类图来展示类间关系，描述清楚接口设计的一些思考原则
提供的接口，往往接口设计为了完成相关逻辑。基于接口开发，多用抽象思想，更多是让代码阅读性更高一些。
# 5.5 模块间依赖关系
描述清楚和哪些模块存在依赖关系以及原因，比如首页依赖于购物车模块，需要解释清楚要强耦合，有没有办法解耦
- App内部模块间依赖
- App外部依赖
注意不要大杂烩，我只想要某个业务功能。你然后给我一堆乱七八糟的依赖，不要不要这种！
# 5.6 UI/动效设计
客户端开发有很大一部分精力在UI/动效上，对于复杂的静态UI和复杂动效，需要给出实现方案和选型逻辑
静态UI：只有复杂的UI才需要给出设计方案，例如核心页面大重构、复杂的协调布局等
复杂动效：复杂的动效是端上容易踩坑的关键点，需要给出实现方案的对比、选型等，为验证动效可行性，可以给出动效Demo
# 06.其他设计说明
以下部分是可选项，主要是从异常、兼容性、性能、稳定性、灰度、降级、代码设计规范等维护来设计。
# 6.1 性能设计
有些业务项目可能会考虑性能，比如页面，卡顿、流畅度、内存泄漏怎么样？如何评估？
有些技术项目可能也会考虑性能，比如数据库设计，检索性能如何？是否有瓶颈，如何评估？
# 6.2 稳定性设计
大的项目需要考虑性能如何保障？
- 比如方案 Review
- 比如自测Case Review，加强自测
- 比如单测，检测内存是否泄漏，是否存在对象销毁问题
# 6.3 灰度设计
核心关键功能需要有A/B设计，功能开关等
比如UIWebview替换为WKWebview，其中存在很多不确定因素，需要做好灰度设计
# 6.4 降级设计
在做一些新技术尝试时，需要考虑降级设计
比如RN、swift、weex引入对原有业务造成影响的，需要有兜底，可降级
# 6.5 异常设计
大部分业务需求都会涉及到异常处理，在关心主流程的同时需要关注异常场景怎么保证正确性？
比如用户操作中途退出、网络异常、数据被清理等
# 6.6 兼容性设计
业务逻辑一般不会涉及到兼容性，但UI/动效需求容易遇到兼容性问题，也是提测时需要让QA关注的
比如独立端/嵌入端、高低版本API适配等、比如Android不同版本兼容设计
# 6.7 自测case设计
作为实践写代码，这个过程自测case罗列一下，然后自测，自测一项勾选一项
# 07.排期与计划
排期计划主要针对周期较长项目的时间补充，对于小型项目不需要，例如：
正常的版本业务需求，5pd以下，不需要给出排期计划；5pd或者以上，可以简单描述一下排期和提测时间
跨版本的大型业务需求、重构专项等，需要给出详细的排期计划
研发自驱的技术优化项目，需要给出详细的排期计划
# 7.1 排期节点
这个很重要。尤其是针对一个大型的需求开发，需要有一些关键节点，有利于掌控项目的整体进度。
# 7.2 落实反馈
建议排期把业务中细节拆分然后使用番茄工作法
比如针对一项较大的任务，把任务尽可能拆分的很细。细到可以立马执行那种粒度，做完一项就勾选一项！
# 08.参考资料
需要列出方案设计过程的文档，包括但不局限于PM需求文档，技术参考文档等。
# 8.1 参考内部资料
这里可以罗列需求文档，一些内部资料。需要备注信息。
# 8.2 其他参考内容
针对某一个项目的技术点，如果有参考博客，则罗列出来，主要是方便后期查阅。
针对某个功能代码的拷贝，如果有参考技术demo，则需要贴出来。尤其是开源项目，则需要分析项目的可达性，稳定性，维护性等。
