01.技术设计的文档

目录介绍

• 01.整体概述介绍
  • 1.1 项目背景
  • 1.2 遇到问题
  • 1.3 基础概念介绍
  • 1.4 设计目标
  • 1.5 产生收益分析
• 02.核心技术点
  • 2.1 技术点梳理
  • 2.2 困难点说明
• 03.业务场景梳理
  • 3.1 业务梳理点
  • 3.2 核心逻辑说明
• 04.方案设计思路
  • 4.1 技术调研分析
  • 4.2 方案对比论述
  • 4.3 总体设计思路
• 05.方案基础设计
  • 5.1 整体架构图
  • 5.2 UML设计图
  • 5.3 关键流程图
  • 5.4 接口设计图
  • 5.5 模块间依赖关系
  • 5.6 UI/动效设计
• 06.其他设计说明
  • 6.1 性能设计
  • 6.2 稳定性设计
  • 6.3 灰度设计
  • 6.4 降级设计
  • 6.5 异常设计
  • 6.6 兼容性设计
  • 6.7 自测case设计
• 07.排期与计划
  • 7.1 排期节点
  • 7.2 落实反馈
• 08.参考资料
  • 8.1 参考内部资料
  • 8.2 其他参考内容

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，则需要贴出来。尤其是开源项目，则需要分析项目的可达性，稳定性，维护性等。