前言

理想很丰满

以前我一直期望的团队效果：
无为而治，百花齐放。每个人都有自己的技术沉淀，自己的思维习惯，充分发挥每个人的能动性，在微服务体系里，职责划分好，大家各自能够承担自己的模块。
输入：可对接产品，完成需求评审及需求分析
输出：产出技术方案，完成技术方案文档编写，发起技术方案评审，并进行研发，交付工作。

团队确实需要统一、协同，不能太自治，这样就少不了规范和模板

后来，多少公司会制定各种规范，大家一直都在施行和遵守，我就不需要再去挑战了；
团队的人员每个人都按照自己的想法进行技术文档编写,导致质量参差不齐，缺少统一规范每个人的都要逐一深入理解，后来人难以阅读等等。

技术方案设计文档模板的重要性

可能你所在的公司或者团队，很正规，有各项管理规范；也可能你所在的公司或者团队，还没有形成。我个人认为程序员的技术方案文档很重要，是知识沉淀，是传承很重要的媒介。有一个好的模板就显得尤为重要：

统一技术语言和概念：技术方案设计文档模板明确了团队成员之间交流的技术语言和概念，有助于避免因理解不一致而导致的沟通障碍。
提升工作效率：通过使用标准化的技术方案设计文档模板，团队成员可以更快地理解项目需求，减少重复性工作，提高工作效率。
强化团队协作：技术方案设计文档模板可以为团队成员提供一个共同的工作目标和方向，增强团队的凝聚力和协作效率。
风险管理：技术方案设计文档模板可以帮助团队识别和评估潜在的技术风险，从而提前制定应对策略，降低项目风险。

一个团队应该有自己切合实际的模板（比如常出错的模块，比如风险较高的模块），他能够帮助团队成员尤其是新成员，避免踩前人踩过坑。

我不断总结优化的技术方案设计文档模板

一直是在实际使用过程中不断积累和调整的，希望能对jym有所帮助

技术方案.png

技术方案设计模板

技术方案本质上需要回答两个问题：

其一，为什么该方案可行？

其二，在已有资源限制下，为什么该方案是最优的？

为了回答第一个问题，我们需要在技术方案里补充架构图、接口设计和时间人力估算。

而要回答第二个问题，需要我们在关键点或争议处提供二到三种方案，并给出建议方案，这样才有说服力。

通常情况下，我们会花费很多的时间准备第一个问题，而忽略第二个问题。

其实，回答好第二个问题很重要，大型项目的设计已经复杂到没人能够一次就想到最佳方案，一个仅仅“可行”的方案，可能会给系统增加额外的复杂性。

**使用方式**

此模板旨在给大家**编写技术方案**以及做**方案评审**时查缺补漏，
如有部分章节项目不涉及，可以不写，但是需要保留整体结构。

一、背景

讲清楚what+why，介绍项目的背景、相关系统的现状以及相关名词定义。
着重说明项目以下问题：
必要性（为什么要做）
风险（不做这个事情有哪些影响）

二、目标

要达成的效果，最好是与问题对应。

如果是产品的需求，这里直接贴需求对应的目标

业务需求是什么？项目产出是什么？衡量指标是什么？

三、整体设计

描述功能架构及技术架构

3.1、系统调用拓扑

描述涉及服务间的调用拓扑

3.2、业务架构图

描述本次需求在业务架构图中是如何拆解层级的，体现模块划分

3.3、技术架构图

描述技术架构方案

3.4、整体流程图

描述需求涉及的整体流程

3.5、阶段规划

描述对技术方案的整体规划与阶段拆分

架构的演进规划

每个阶段的目标与达成的效果

四、详细设计

方案部分，重点讨论：How，怎么做。

如果是概览的方案，则需要描述清楚

宏观的架构，主要是模块的关系（组织方式）

模块的定义，定位、职责、边界、输入输出

对于技术中出现的一些具体的技术难点，则需要描述清楚怎么做的。

4.1、流程图

描述**各种分支情况的条件及处理逻辑。要覆盖所有流程分支，不重不漏。

4.2、模型/数据结构设计

可以单独一个文档维护，将链接附在这里

表结构设计，包含： ER**图、建表语句 . 参考： [02.数据结构设计-v1.0.0]**

是否新增表

是否有 DDL 操作（这里要重点评估，涉及DDL，还要评估表的数据量影响范围）

是否有 DML 操作

4.3、核心/关键逻辑描述

流程图中系统最关键逻辑的具体说明，重点说清楚本系统最关键部分的处理逻辑

核心算法、 分布式锁 与 分布式 事务控制、数据一致性保证、消息可靠性

异常边界

4.4、数据产出逻辑

从**原始数据 到最终结果过程中的关键计算逻辑说明，包括该逻辑在系统中的的应用场景，及具体逻辑实现等。关键数据指标（需要自测和部分QA测试时验证正确性）

4.5、定时任务

4.6、资源环境准备

4.6.1、服务与服务依赖

是否申请新服务

是否有基础服务调用，是否需要开通白名单

是否有其他模块服务调用依赖

4.6.2、相关中间件

MQ 、缓存等

4.6.3、数据库

是否新创建数据库实例

4.7、环境确认

4.7.1、客户环境jdk版本确认

防止出现高级别语法，导致客户环境报错

ToB的产品交付场景中有遇到

4.7.2、客户数据库确认

确认客户使用的数据库产品，若出现oracle和mysql等其他数据库，需要做兼容 ToB的产品交付场景中有遇到

五、接口文档

可以单独一个文档维护接口文档，将链接附在这里

参考： [03.接口文档-v1.1.0]**

六、稳定性保障

系统相关的监控，降级，回滚，业务灰度方案等措施。

七、版本兼容设计

是否涉及历史数据的处理、历史版本的兼容处理

八、风险点

如有相关风险点，可以记下来。包括思考点，结论，备注等信息。

九、任务拆分及研发排期

精确到天的时间安排和人员分工，有明确的检查点

十、评审记录

评审类型	评审时间	评审人	评审意见
内部评审
外部评审

【研发管理】-技术方案设计的规范与模板

前言