本文介绍写技术方案的意义、如何评价技术方案的好坏、如何写技术方案。
写技术方案的含义写技术方案的根本目的是提高研发效率和质量，具体表现在以下几个方面。
1、提高沟通效率
通过技术方案文档和审阅对齐提高整个团队的交流效率：
产品管理员可以审查技术方案是否与产品设计有偏差，是否满足当前产品需求和后续产品设计计划；
开发leader可以确定控制方案是否满足技术要求，包括技术规范、性能要求、复杂性实现、可扩展性等；
测试学生掌握需求技术的实现原理、变更点、影响点后，才能进行有针对性的测试用例设计；
接手后续项目的同学可以通过技术方案文档熟悉系统。
2、提高开发效率和质量
针对开发者，通过编写技术方案，提前梳理需求和实现，减少等到编码阶段前期考虑不到位导致返工，再写技术方案再进行编码，编码时思路更加清晰，编码效率和
如何做好技术方案如何做好技术方案，至少要满足以下三个条件。
1在谈到思路清晰的技术需求时，常见的问题是马上提出解决方案，参与者不能理解为什么要这样设计。 其实，比起解决方案，如何思考、思考的过程非常重要。 思想是思维的线索，是思路清晰的方案，层次清晰，让参与者能够快速理解。
整个技术方案的思考线索可以通过5W2H分析法联系起来。 Why、Who、When、Where、What、How、How much () )从七个方面进行分析思考，如下图所示。
整个技术方案首先需要根据需求背景，明确界定需要解决的问题，明确目标，明确Why。 明确界定问题后，从When、What、Where、How等不同角度，分析和解决问题。 首先讲总体结构，然后细分流程，主线先，分支先，正常链路先，异常链路先。
2满足需求的技术方案满足的需求包括功能需求和质量需求。 功能需求不仅是当前产品提出的功能需求，还要求对未来需求的扩张做一定的规划，确保扩张点，开发在规划设计之前，要充分收集和分析现状和需求。
除了功能需求，更考验开发同学技术能力的是质量需求，包括异常处理、降级方案、灰度方案、运维方案、高可用性设计。 设计时要结合具体业务场景，在当前项目阶段，进行合理权衡，避免陷入极端。 或者在所有方面过度设计； 或者方案太粗糙，考虑不够。
3可以实施这样评价一个技术方案是否可以实施。 技术方案完成后，其他人能否按照技术方案按时完成质量开发并上线？ 部分技术方案从上到下看，从上到下看，但开发实施困难。 一般原因如下。
不够细:未明确说明变更涉及的字段、消息、异常情况、边界情况、历史数据兼容性等处理
做不完:方案调整太大，可以解决问题，但实施时间不够
编写技术方案时，方案要充分完善、详细，要考虑和完善开发中的重要内容。 如果这些点没有先明确定义，开发时才发现与系统目前的现状相矛盾，或者容易偏离方案的设计进行开发。
方案设计也要考虑时间、开发成本、系统现状、是否符合团队可获取的资源。 一部分方案从技术的观点来看是最佳的，但从实施的观点来看不是最佳的。 例如，追加引入与上下游系统相应的变更，带来一定的沟通合作成本。 因此，方案设计在考虑产品和技术等限制的同时，还需要考虑当前现状、要求的在线时间等其他因素，选择最合适的技术方案。 可以在方案中写不同实现的评价比较，取舍选择，将方案分解到不同的开发实施阶段。
程序的配置前提是定义明确的业务流程，并明确预期预期结果。 技术方案的各构成部分以产品的整个研发周期为中心，在一张图上归纳如下。
1要求说明为什么产品文档中说明了要求？ 技术方案中还写有必要条件说明吗？ 主要原因如下。
介绍需求:通过在技术方案中简明扼要地介绍产品需求，有利于其他技术方案的人快速了解需求，有利于以后具体技术实现的出发点。
对齐需求:需求说明部分体现了开发学生对产品需求的理解，在技术评审阶段与产品学生的检验再一次保持一致，减少理解产生偏差。
需求说明包括需求背景和分解。
(1) 需求背景
说明为什么需要制造这个需求，需求的价值意义是什么。
(2) 需求拆解
从需求实现维度分解为相对独立于需求的子需求，概要说明各子需求的内容，可以根据实际情况以不同的角度进行分解。 一般分解的角度如下。
实施步骤
功能模块、业务领域
对外提供的接口、服务
2概要设计思路不清晰的技术方案存在常见问题。 在说明需求背景后，直接开始介绍各子需求的具体实现。 这种技术方案各部分松散细致，不统一于整体，不容易阅读掌握。 这些设计背后的想法是什么，为什么要这样设计？
>概要设计包括系统现状，总体思路和系统架构。
(1) 系统现状
为什么需要写系统现状？一方面是有些产品需求文档涉及系统现状这块并不清晰，例如需求文档写成“在系统当前实现逻辑的基础上，进行xxx调整”，因此需要在技术方案对系统现状进行补充说明。另一方面，介绍系统现状能方便理解后续设计的出发点，在技术评审时方便评估当前设计的合理性以及是否有遗漏的点。
系统现状可以针对需求的内容，需求影响点来介绍，常见的内容可以介绍系统当前处理逻辑，历史数据的数据量，请求量，数据增长量等情况。写系统现状时，不需要面面俱到，而是结合当前需求，针对性地重点介绍与需求相关系统的情况，为接下来介绍总体思路，系统架构做铺垫，其他不太相关的现状可以简单带过或者不介绍。
(2) 总体思路
写总体思路可以为后面介绍整个详细解决方案奠定基础：对方案进行信息压缩，后面的详细方案介绍都是围绕着总体思路进行展开，使得整个方案阅读起来方向明确，思路清晰。总体思路的内容是概括性介绍需求实现涉及关键问题的解决方案。
(3) 系统架构
概要设计中的系统架构是总体思路进一步补充，说明系统总体上的架构设计，画系统架构图是介绍清楚系统架构的有效手段。在概要设计中的架构与详细设计中的架构的关键区别在于，前者关注系统整体处理，后者关注子需求的具体实现。在概要设计中介绍的架构图常见的归类有：
按照系统模块和处理流程介绍，介绍各个模块处理的步骤，系统间的交互。
按层级介绍，把具有相同属性或特征的信息块归为同一个层级，例如系统MVC分层架构。
画图时，注意不要想在一张图里面做到面面俱到，画之前要想清楚这张图要表达什么内容，传递什么信息，再针对性来画，不同的类型的图不要合在一起。例如想说明系统的部署结构用部署图，说明业务的主要流程用流程图；如果图里面，既有系统部署涉及的基础组件，又有业务处理流程，图表现出来的信息就比较混乱。
3 详细设计详细设计可分成开发约定，功能实现，可维护性设计，可靠性设计，方案选择。
(1) 开发约定
开发约定部分常见介绍的内容如下：
方案新引入的名词，概念的解释，方便后面的内容引用。
前期上下游对接达成一致的约定/协议。
(2) 功能实现
软件系统工作的核心功能是对数据的处理。因此在技术方案介绍具体功能实现时，重点关注的点是数据链路，包括：
数据源：系统的流量来源、业务在何时何地触发，例如对外提供的接口，定时任务，MQ消费等
计算转换：数据如何做转换运算，加工处理的流程
存储：数据存储设计
为了介绍整个数据处理流程，体现在以下方面：
接口设计：提供接口设计文档，包括入参出参字段定义，接口参数校验逻辑，异常情况的处理和返回的错误码。
系统间交互流程：结合系统间流程图说明整笔业务请求涉及哪些系统组成部分，业务的发起来源，系统间交互调用了具体哪个接口，请求处理基本步骤和数据落地存储逻辑。
系统内处理流程：结合业务处理流程图说明请求如何加工计算数据，处理的具体步骤，最终处理完成之后结果如何保存，或者传输到什么地方。
存储设计，包括存储结构（包括MySQL、ES、Redis、OSS等）设计，包括表和字段的概念定义，各个表之间的关联，业务系统如何使用这些库表。
(3) 可维护性设计
可维护性设计关注的是后续系统的迭代升级，需求变更，系统怎么维护的问题。这块的关键点主要是代码复杂度问题，不好维护的系统，会因为系统引入一个新需求，整个系统需要做大量改动。因此系统需要考虑通过提前做一些可拓展设计方便后续维护，体现在以下方面：
拓展点分析：结合产品需求分析后续扩展带来的变化点，为了支持这些变化系统需要预留哪些扩展点。
系统建模：针对变化点，对系统对象进行建模，主要关注：模块（职责明确的模块或者组件）、关系（组件间明确的关联关系）、边界（约束和指导原则）。
设计模式：使用设计模式时，要注意设计模式的底层逻辑是“找到变化，封装变化”，将变化封装在可控范围内，具体介绍设计模式涉及的类图，以及拓展新需求时，系统需要做的变动。
配置项：包括配置项的具体定义，使用注意事项。
(4) 可靠性设计
可靠性设计包括以下要点：
灰度方案
如果是新系统初步上线用于替代老系统，新系统还需要经过进一步线上验证，这时需要考虑灰度方案，包括灰度的周期计划，灰度的范围/维度，灰度配置策略。
容量评估
容量评估需要根据请求量，评估要预留给程序多少相应的运行资源。包括内存，磁盘，CPU，存储服务等。评估的点包括：接口平均QPS、峰值QPS、接口请求和返回报文大小，消息队列的平均消息数、峰值消息数、报文大小。这一部分如果是改动的业务，可以参考以前的监控，如果是新业务或者新活动可以跟运营、产品确定业务量。若预估峰值会很高，需要进行压测。
监控报警
当方案不确定性比较大，容易出错，一旦出错造成的影响较大，需要加监控告警，说明的信息包括：模块，监控指标，监控阈值，报警方式等。
(5) 方案选择
当我们设计了一个方案之后，评估这个方案是不是最优方案最简单的办法，就是看看还有没有更优的方案。不同方案如何做评估选择？可以做360度全面评估对比，具体的操作方式为：列出我们需要关注的质量属性点，然后分别从这些质量属性的维度去评估每个方案，再综合挑选适合当时情况的最优方案。
常见的方案质量属性点有：性能、可用性、硬件成本、项目投入、复杂度、安全性、可扩展性等。在评估这些质量属性时，需要遵循架构设计的原则：“合适原则”和 “简单原则”，避免贪大求全，基本上某个质量属性能够满足一定时期内业务发展就可以了。
4 测试方案良好的测试用例设计能有效提高开发质量，技术方案中不仅需要考虑开发自测，为了进一步提高研发质量，还需要考虑如何提高测试同学的测试质量和效率。技术方案在测试这块需要考虑的点包括：影响点，自测用例，测试注意点。
(1) 影响点
影响点可以用清单的形式列出本次开发影响了哪块功能，哪些接口，接口url，改动的内容是什么。这样测试同学在设计测试用例时可以做对照参考，减少功能遗漏测试的情况。
(2) 自测用例
自测用例是介绍说明需求自测的用例设计，可以用清单的形式列出，一般包括涉及场景，测试步骤，测试输入，期望输出等信息。
(3) 测试注意点
有些隐藏的异常情况处理，边界条件，特殊处理逻辑，如果没有特别说明，测试同学测试的时候很容易遗漏这块，而线上bug往往出现在这一块。所以可以在方案里面特殊指出这块，让测试同学在测试的时候特别注意一下。
5 上线部署不想需求上线后各种问题，疲于应对，那就有必要在技术方案阶段考虑上线部署的问题，在技术方案设计中先提前准备好，等到上线阶段对着技术方案写的注意事项，步骤进行一步步检查和执行，减少上线事项遗漏或者处理出错的情况。
上线部署部分涉及的点包括环境准备，系统准备，发布顺序，线上验证；
(1) 环境准备
系统依赖环境的准备包括MySQL、Redis、MQ、ES和Nginx等服务搭建和初始化，机器资源等。
(2) 系统准备
系统准备常见主要如下：
依赖的服务配置，数据更新，例如数据库表创建，SQL初始化脚本，Nginx配置更新，MQ的topic创建，网络端口打通，监控配置，IP白名单申请，定时任务创建。
引用服务项目配置更新，代码检查，分支merge。
(3) 发布顺序
发布部署的服务之前有业务依赖关系，被依赖的服务需要先发布部署，如果这种依赖关系，在技术方案中应当标明。
(4) 线上验证
线上验证的部分，需要说明服务部署之后，怎么验证服务是否正常，需要做哪些检查验证项。例如telnet检查端口是否通，日志是否有报错，通过线上测试账号走一笔业务看看是否正常，监控面板要看哪些指标。
在开发和测试阶段，当配置项，脚本，配置出现更新调整，需要更新保存在技术方案文档里面，上线时照着文档操作，不容易遗漏。
总结想成为优秀的开发人员，不能只局限在开发领域，而是必须要有跨界的意识，包括产品意识，测试意识、项管意识和运维意识：
产品意识：理解产品的具体业务流程是什么，产品为何这样设计，目前业务规划的发展方向，主动沟通产品方案中的不合理之处，提供参考解决办法。
测试意识：技术方案中要考虑测试同学如何测试，提供必要的细节信息支撑测试，例如数据更新存储流程。开发提测前对涉及的影响点做必要的自测，主动沟通测试同学的测试方案的不合理或遗漏的点之处，提供参考解决办法。
项管意识：对任务进行合理分解，在开发、测试、上线流程中，要及时发现影响整体进度的问题点，主动协调解决或者上报反馈，按照计划主动推进项目保障最终按时按质上线。
运维意识：对系统的日常运维、容量和系统瓶颈、系统流量增大扩容方案要有一定的认识和解决方案，保障业务正常使用。
工具推荐
思维工具：结构化分析法、5W2H分析法
脑图软件：Xmind、百度脑图
画图软件：ProcessOn、PPT、PlantUML