七步技术方案编写技巧分享

一、背景

工作中，有一些需求或者技术改造，老板总是会要我写出一个技术方案先和他对一对，作为程序员，我相信大家工作中也经常要出技术方案，技术方案有没有一些套路呢，根据多年来的经验，其实是有的，本文就把平时写技术方案的套路总结出来，有需要的同学可以花几分钟时间看下。

二、技术方案重要性

开发人员写代码前，系统设计是不可少的，特别是涉及到新功能或者比较大的系统变更，一般都需要技术方案，技术方案是整个项目相关人员都需要了解的，比如系统关联方，前端，,产品和其他维护人员，有时候我们的老板也希望能看到我们的技术方案，通过技术方案，更好体现工作量和系统涉及到风险点，还能给项目相关方都看看方案是否合理。还有我们做开发久了会发现，如果一个功能想清楚怎么做了再去落地写代码，写代码的效率会更高。

本文将结合作者多年工作实际经验和具体案例，对技术方案怎么写来做一次总结，如果你不知道怎么写技术方案，可以先收藏起来备用。大家可以在评论区分享如何写一份比较好的技术方案。

三、常见的技术方案有哪些内容

1、系统用例

这部分能最简单的反映系统的使用者和系统功能的交互，是系统功能的蓝图。

一般会涉及到用户端和管理端的用例，可以通过用例图反映，比如退款申请功能用例：

2、功能整体链路

这部分是将用例以及各个系统串连起来，有序的完成整个功能的交互，我们可以通过时序图来表示。

通过这部分，可以反映功能涉及到的上下游系统，可以明确到相关接口层面，或者消息等，能体现相关方的工作量和风险点。比如下方用户申请退款的时序图简图，作为交易服务，需要依赖支付服务。

3、核心业务流程

这部分相对于第1部分是更细节更详细的设计，是关于业务功能里比较核心的业务逻辑，是一个大功能里对业务起关键作用的流程，比如发起退款里面，对退款的状态变更是比较关键的流程，我们一般要把这种核心功能的流程体现出来，可以用时序图或者流程图，流程图表示可以更直观，对于有一些数据或者状态变更的操作可以给一些推演案例，这点一般测试人员会比较关注。

下面是退款流水表退款状态的推演记录：

3、数据库设计

这块内容是对数据库变更的体现，数据库是我们业务系统的最底层，数据库变更应该是需要重视的。我们需要考虑数据库设计的合理性。

是否有新表引入，以及是否有必要性，需要注意新表是否需要分片,考虑数据量增量大小，是否需要定期归档

旧表新字段引入，需要关注新字段是否引入慢查询，是否有大字段，是否有敏感字段，是否需要加索引等，有比较多的情况新功能导致慢sql。

我们可以把ddl语句在文档中体现出来，突出是新增还是更新。

退款流水记录表order_refund_record(新增)

CREATE TABLE 'order_refund_record`(
`id`bigint(50) unsigned NOT NULL AUTO INCREMENT COMMENT 'id', order id` varchar (50) NOT NULL COMMENT'订单id',
`refund_status` int(4) NOT NULL COMMENT'退款状态0初始化，1退款中，2退款成功，3退款失败'，
'create_time' datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT'创建时间'，
`update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT'更新时间'
`is_delete` tinyint(3) unsigned NOT NULL DEFAULT 'O' COMMENT'是否已删除0-未删除1-已删除' 
PRIMARY KEY (`id`),
) ENGINE = InnoDB DEFAULT CHARSET =utf8mb4 COMMENT-'退款流水记录表';

4、接口设计

这部分是比较细节的设计了，一般是用于提供给前端或者上下游系统，通过接口设计可以让相关方了解满足需求。

这部分有rpc接口或者http接口，也可能是消息，需要把传输的数据结构定义明确出来，特别是业务关键字段，让相关方能够评估改动点，可以知道新接口或者新字段是否可以满足需求。工作中常用的接口文档有yapi和swagger。

除了定义接口数据格式，接口设计需要考虑性能，比如，是否需要限流。

5、非功能设计

5.1、性能与稳定性

非功能设计里面性能和稳定性应该是需要比较看重的，我们做的功能最基础的要保障稳定可用。

比如新功能如果有新增配置表，我们可以考虑配置表是否放缓存，避免直接查询数据库，特别是配置表查询qps比较高的情况。

比如依赖多个下游服务，下游服务之间互不依赖，我们可以考虑使用多线程异步并行处理，提高接口吞吐量。

5.2、监控

这部分也是很重要的，我们做的功能上线后怎么知道有没正常运行呢？我们除了看数据库，查日志，比较好的方式就是系统自己有业务监控，业务打点，通过业务监控可以实时查看业务的实际情况。

比如抽奖活动发奖励的业务功能，我们可以把参与抽奖活动成功，失败，发放各类奖励的数据记录到监控平台，监控平台可视化展示业务监控。

5.3、核对

这是对于一些核心业务功能必须要做的事情，通过核对对账可以确定我们做的功能有没有漏洞，避免公司损失。

核对一般有实时核对和离线核对，比如营销活动发优惠券奖励，我们需要核对营销活动发放规则和发放优惠券是否正确，避免出现超发，漏发，错发的情况。

6、系统风险点评估

这部分我们要思考新功能对系统有哪些风险，比如新功能引入对现有功能的影响点风险点，比如功能流量大对系统稳定性是否有冲击，再比如对依赖服务是否有影响。可能还需要考虑如下点：

• 数据库是否需要扩容
• 缓存是否需要扩容
• 新功能是否需要压测
• 新接口是否需要限流

四、总结

技术方案应该是相关方共同参与并且需要达成共识，技术方案需要考虑现有的资源成本，现有系统影响，以及合理性多方位来分析，通过技术文档可以让相关方理解整个功能的业务流转逻辑，对于后续工作推进也有一定作用。

到此这篇关于七步技术方案编写技巧分享的文章就介绍到这了,更多相关技术方案技巧内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

最新评论