如何写出一篇好的技术方案？

近期在写某个项目的技术方案时，来来回回修改了许多版，很是苦恼。于是，将自己之前写的和别人写的技术方案都翻出来看了几遍，产生了一些思考，分享给大家。,我们为什么需要写技术方案?总结下来无非是几点，从不同人的视角来看：,我们都知道技术方案是指导具体开发工作的，可以分别从开发的事前、事中、事后来讨论这个问题。,一篇好的技术方案可以贯穿整个研发的生命周期，并且能起到很好的指导意义，就如同写小说之前作者必须出一个大纲的逻辑是一致的。,那么，如何写出一篇好的技术方案呢?下面列举出笔者认为应该做到的一些点。,一份技术文档需要有一个清晰的目标(业务需求建议自己总结而不是 Copy from
PRD，技术自发的那肯定得自己总结)，那目标怎么来的呢?是从需求里转化过来的。那么，如何将对应的需求转化为一个清晰的目标?我认为最重要的是要尽量定义一个可衡量的标准。需求的种类一般来说就两种，分别是：1.
,1.产品类需求——业务方 or 产品方发起提给技术，包括但不限于以下几种：
,2. 技术类需求——技术自发提出，包括但不限于以下几种：,在众多的需求当中还有一些是我们要去辨别的伪需求——不是用户真正想要的需求，如用户想要将一个飞机改造成火箭，但是产品可能提过来的仅仅是把飞机的两个翅膀砍掉，那么砍掉翅膀就能变成火箭了吗?明显不能，所以这种需求一定要注意鉴别。,有句话叫“不谋全局者不足谋一域”，在技术方案中我想也是如此。在一个技术方案中，一个大纲图是不可或缺的
，有的人叫它技术架构图，有的人叫它数据流转图，这都不重要，重要的是我们能从这张图中看到整体的脉络，那么这张图需要有哪几个要点呢?
,大纲图的逻辑示意参考,讲到数据模型设计，E-R 图是必不可少的，E-R 图应该包含以下信息：,技术方案 1：需要依赖缓存、分布式调度中间件、消费外部的消息，但是没有把对应的中间件使用方式、数据格式贴出来。,技术方案 2：需要依赖缓存、分布式调度中间件、消费外部的消息，将缓存接入的方法 & 对应的缓存 key-value
设计写清楚，将分布式调度中间件接入所需要准备的依赖项梳理好，将外销消息对应的 topic 和数据格式列清楚。,两个方案对比好坏其实很明显。如果一开始我们在技术方案里面将外部依赖确定好，那么我们在开发的时候就一马平川，反之如果外部依赖都不确定的情况下就进入到开发，那么返工的概率将大大增加，从而降低我们的工作效率。,那么，对外的依赖有哪些以及我们应该要确认什么信息呢?下面列举了一些常见的依赖情况：
,模块依赖层次从高到低分为：,我们举接口依赖的例子来看：一共三个接口分别是滚存看板查询接口、锁接口、渠道集接口，滚存看板查询接口依赖于锁接口和渠道集接口。,技术方案 1 目录层次：滚存看板查询接口、锁接口、渠道集接口;,技术方案 2 目录层次：锁接口、渠道集接口、滚存看板查询接口。,很明显，技术方案 2 是更加合理的，A 依赖于 B 那么 B 应该先做。我们在写技术方案的时候，要考虑什么应该在前什么应该在后，而不是想一步写一步。要有一个清晰、有序的结构，不然别人看起来就会是杂乱无章的。
,下面列出一个技术方案的模块里面应该要写哪些东西，供参考：,要求：实现一个飞机运力合同查询接口，入参为运力大区,技术方案 1：,技术方案 2：,技术方案 2 是更好的，为什么?测试、前端 、后续要接手该接口的人都能够一下子找到你的接口并清楚知道输入输出是什么。另外，1 和 2 的入参一个 area 一个 cnArea，那么到底哪个更对呢?这里由于系统中在用的都是 cnArea，固沿用 cnArea 是对的(一致性减小沟通成本)。
,这里总结对接口定义有几点要求：,要求：实现一个学生信息查询接口。,技术方案 1：写出查询结果中执行的相关步骤。,技术方案 2：在 1 的基础上使用时序图表达出来。,推荐使用技术方案 2，好处是尽管内容相同但是时序图能够更直观地看到层次、数据流转等信息。,除了以上比较基础的 2 点，我觉得的还有一些要点：,要求：实现一个定时任务，定期将过期的数据删除。,技术方案 1：使用 spring 自带的定时器进行数据清除。,技术方案 2：使用分布式调度中间件(如 schedulerx)进行定时过期数据清除。
,乍一看好像都能实现，但仔细对比两个实现方式之后我认为大部分人还是会选择技术方案 2，为什么?下面列出一些在选择技术方案时考虑的点。,安全生产包括几个部分，包括且不限于下面几个部分：,我们举一个例子。,需求：在消费者收货成功时触发对商家的结算。,技术方案 1：******，写了一堆如何触发结算、如何更好地支持后续的可扩展性;,技术方案 2：******，写的方案可扩展性没有技术方案 1 高，但是做好了未触发结算的监控、触发结算之后的对账，并设计好了对应的报表防止出现资损。,其实这也是我们在技术方案中可能会忽略的一点——埋头于代码结构如何如何的好，但是有些东西其实是要比单纯的代码更重要。就比如风险控制，完备的监控、不可缺少的对账是保障公司资金安全，更是保障我们自己绩效的工具(此处应有表情)。
,那么对于监控、对账的具体要求是什么呢?我认为有以下几点：,还有其它几个部分也补充说一下：灰度方案，包括但不限于：,向前兼容性，包括但不限于：,发布流程，包括但不限于：