一个好的技术方案

by tong

技术方案：是为研究解决各类技术问题，有针对性，系统性的提出方法、应对措施及相关对策。

对于我们程序员来说，技术方案是贯穿整个开发周期的，因此写出一个好的技术方案是很重要的。那么怎么样的技术方案才能算得上是一个好的技术方案呢？我们可以从以下几个方面进行分析。

面对的是谁

即写出技术方案以后谁会看到这个方案，谁会对方案提出问题和意见，大致有这几类：产品经理、测试、同事&leader、新人。一份好的技术方案应该是表述完整，清晰，简洁的，对于评审者和我们也是有很大的意义的

产品经理：通过技术方案，产品经理可以知道我们实现的内容，了解我们的实现是否符合预期，避免开发中出现需求无法实现需要和产品经理反复协调的问题
测试：测试可以了解我们的实现流程，数据流转等，对写测试分析时也有一定的帮助
同事 & leader：一般来说，同事和 leader 是最了解相关代码的人，能帮助我们找出疏忽点，验证方案合理性
新人：当新人进入团队时，一份好的技术文档能帮助他很快了解业务，快速进入开发状态

作用是什么

技术方案贯穿我们开发的全过程，一份好的技术方案能在每个环节都起到了相应的作用

开发前

明确目标 🎯
分析技术可行性
进行技术选型
降低沟通成本

开发中

指导我们的代码实现
减少编码过程中的各类变更，缩短工期
开发后
尽可能地减少 bug 产生
帮助我们进行项目复盘

但是并不是所有人的技术方案都是好的技术方案，只有我们重视技术方案并且不断改善，才能写出一份好的技术方案

如何写好技术方案

此次技术方案针对是我们公司以及我的个人经验，不能一概而论，需要具体问题具体分析

技术方案一般可以分为 4 个部分：项目背景、系统架构、具体设计、非功能性需求

项目背景

首先我们技术方案的项目背景要和产品 prd 区分开来，产品 prd 更加注重的是业务背景，但是产品是不了解我们系统设计、代码设计的，因此在我们编写项目背景时需要注意介绍设计相关的。

业务需求，目标
技术需求，目标
各个功能点占比
…

好的背景介绍能让人快速理解需求是做什么的，限制是什么，为什么要做该需求，并为后面的系统架构和具体设计做好铺垫

系统架构

系统架构的介绍包括但是不限于：术语表、系统用例图、技术架构图、数据库表设计

术语表：术语表能让人清晰快速地了解一些词在系统中的定义，降低沟通成本

术语表应该严格一致，从产品到开发到测试都应该认同该词，并在过程中尽量使用该术语

系统用例图：描述用户和功能之间的关系，展现了系统提供的价值

在画系统用例图时应该要区分出原有的用例和新增的用例，方便参与者查看

技术架构图：在这张图中我们可以看到系统之间的调用，数据的流转和模块的划分

技术架构图不需要画的十分细致，但是需要注意数据的流转和系统边界的划分

数据库表设计：阐明数据库表之间的关系, 以及关键索引(核心查询条件字段)

数据库表设计应该详细，并且也不应该直接将建表语句放在上面，需要考虑到产品等人的理解

具体设计

在进行具体设计时，我们就应该考虑功能的实现了，此时我们需要给出接口的定义，通过技术选型来选择最合适的方案，通过时序图来表示接口流程

接口定义

接口定义时需要明确接口的入参和出参，在具体定义完后，可将接口文档贴上去

技术选型

很多时候实现当前需求的方式不止一种，我们在前期可以尽可能多地收集方案，并在此时进行比较，选择出最合适的那一种

时序图

时序图对比有序列表能更加让人接受和理解。
粒度更细
…

非功能性需求

除了需要满足业务需求、技术需求，还有稳定性、性能、历史兼容性等也会影响我们系统的使用，因此在做技术方案时就应该考虑方案的可行性

稳定性
性能
历史兼容性
……

最后

一个好的结束方案一定不是一蹴而就的，需要不断地修改，需要不断听取别人的意见并且进行修改，当我们写完当前的技术方案后，请记得至少至少自己先复查一遍吧！

back

home

tags: 工作 - 技术方案