资深工程师的技术方案思考模型

我写过千千万万的代码，见过大大小小的 bug，它们告诉我，不想成为 XX 之父的码农不是好程序员，于是我见到了更大的 bug，还是亲生的。

——Bug 之父

软件设计是把需求转换为软件表示的过程，以需求分析为基础进行。从工程管理角度看，软件设计核心步骤分为概要设计、详细设计。实际上，在许多开发团队中，大家不愿意花时间去做完整的设计思考和文档编写工作。仅仅靠口头沟通，一些非常重要的信息和设计思路无法有效同步，信息在传递中的损失率太高，导致软件质量受到长期伤害。为了弥补这种伤害而花费的时间恐怕要比提前做好设计和文档的时间长得多。

没时间写文档？没问题，但起码要有一个完整的思考过程，思考的过程是最重要的。文章的核心内容就是我的思考模型，今天我在这里把它分享出来，希望这篇文章能够成为你日后做技术方案设计时的参考工具。

该模板作为开发团队在软件设计阶段的模板，包含软件设计中 4 个独立又相互联系的部分：架构设计、接口设计、数据设计、过程设计。与质量相关的部分作为重要的补充，目的在于加强前几项设计中对质量保证的充分思考。

架构设计和过程设计需要有图形辅助，可以去找一些免费的画图工具，资金允许的话也可以买付费的用。我推荐亿图图示，图库资源非常的丰富。

以下是模板正文：

1. 项目/需求背景

【按需在此处描述项目背景。通常项目的业务背景是由产品整理并同步出来，有些从技术团队发起的项目则需要技术团队自己整理好背景信息。对背景有透彻的理解，这是资深工程师在产品、技术、用户之间建立联系纽带的起点。】

2. 需求列表

分析、拆分需求，概括重点、优先级排序。

在完成该文档其它部分的编写后，调整列表并注明所需工时（通过设计能拆分出开发任务以及相对合理的排期，反之则说明设计分析不到位）。

技术负责人：吴 bug

任务拆分

3. 体系结构

体系结构，即软件架构。作为软件系统的基础组织结构，描述软件系统中的组件以及组件之间的互动依赖关系。

图形能够形象地表达组件以及组件之间的互动依赖关系，便于读者快速理解，组件自身的属性则需要额外的文字补充说明。

架构图：

【请在此处插入架构图，可以用框图和箭头线表示组件之间的依赖方向】

组件定义：

1. 服务 A：【一句话准确描述该服务的职责】

2. 服务 B：xxxx。

4. 接口协议

系统组件通常以接口的形式对外部对象（其它组件/系统/用户）提供能力，接口协议作为精确的沟通工具，应包括：接口名称/接口描述/网络协议/接口地址/请求参数说明/响应数据说明，最好能有请求示例。

4.1 xxx 接口

接口名称：xxx 接口

接口描述：【描述接口的用途】。

网络协议：HTTP，Method：GET

接口地址：

• 测试：http://xxx/xxx

• 生产：http://xxx/xxx

请求参数说明

请求示例：

curl --request GET \ --url 'http://xxx/xxx?param1=afe343&param2=6uh8'

响应数据说明

Content-Type：application/json;charset=utf-8

响应数据示例

{"code": 40000,"msg": null,"data": {}}

5. 数据结构

业务领域对象的属性、底层存储数据结构、数据报表设计。

5.1 领域对象识别

通过对业务的领域分析，识别出业务实体，并列出实体应包括的属性。领域对象识别是设计底层数据结构的基础，大多采用面向对象分析方法即可，也可以根据具体需求做更高级别的抽象。

5.2 底层存储设计

存储组件为 ElasticSearch 时，须定义索引名称，并在表格中列出以下内容：字段名称/数据类型/含义

存储组件：ElasticSearch 7.10.1

索引名称：xxx

存储组件为 MySQL 时，须定义表名，并在表格中列出以下内容：字段名称/数据类型（含长度）/含义。

存储组件：MySQL 5.8

表名：table_name_sample（示例）

存储组件为 Redis 时，须定义 key 格式，value 数据类型，vaue 的来源和组成。

存储组件：Redis 2.8

key 格式说明：【说明 key 的组成格式】

value 数据类型：【写清楚数据类型，比如 hash】

value 组成：【说明 value 值的含义】

存储组件为 MongoDB 时，须定义文档名称，并在表格中列出以下内容：字段名称/数据类型/含义

存储组件：MongoDB 4.2

文档名称：document_name_sample（示例）

5.3 数据报表设计

报表名称：sample_report_name（示例）

报表用途：【一句话描述报表用途】。

字段设计：

数据生产逻辑：【描述通过哪些数据源、如何处理计算得到报表，如果依赖业务日志的话要同时想清楚日志字段格式定义】。

6. 核心过程

重点功能用例/场景的 UML 时序图

【请在此处插入若干个核心功能的时序图/流程图/数据流图等】

7. 质量属性

质量属性部分我列举了几个基本的点作为示例，每个项目在质量方面的核心关切点可能会有所不同，这里只是抛砖引玉。关于软件质量可以阅读我的另一篇文章：程序员的自我修养-用科学的方法提高交付质量。

7.1 可靠性

容错报警：通用以及特定异常处理（如何容错？怎样进行正向补偿、逆向回滚？监控报警的策略？）

幂等设计：接口/数据操作逻辑的幂等设计，重复操作是否会破坏数据完整性、一致性？

......

7.2 效率

时间特性：

缓存中间件选型与设计（如何初始化？如何更新？过期策略？）、数据库索引的设计

资源特性：

数据冗余是否合理？

怎样降低空间占用（尤其是内存）？

特定场景的并行、异步调度方案？是否支持水平扩容/集群？

......

7.3 安全性

身份认证：必要性分析和方案

权限校验：必要性分析和方案

数据加密：是否涉及隐私数据？隐私保护方案？

......