红河蒙自网站开发,如何做app推广运营,企业官网如何建设,辽源网站seo近期在写某个项目的技术方案时#xff0c;来来回回修改了许多版#xff0c;很是苦恼。于是#xff0c;将自己之前写的和别人写的技术方案都翻出来看了几遍#xff0c;产生了一些思考#xff0c;分享给大家。
我们为什么需要写技术方案#xff1f;总结下来无非是几点来来回回修改了许多版很是苦恼。于是将自己之前写的和别人写的技术方案都翻出来看了几遍产生了一些思考分享给大家。
我们为什么需要写技术方案总结下来无非是几点从不同人的视角来看
产品验证技术方案是否能够 match 上产品方案测试验证技术方案对测试方案是否有足够 准确的输入同事 leader参与技术方案评审验证技术方案的合理性新人(不单单指新同学也指新接触这一块的同学)拿到技术方案可以很快对某一块的事情熟悉起来
什么样的技术方案是一个好的技术方案
我们都知道技术方案是指导具体开发工作的可以分别从开发的事前、事中、事后来讨论这个问题。
事前
明确的目标整个技术方案要达成什么目的低沟通成本产品测试能从技术方案上获取足够的输入不需要反复找你确认技术选型思考为什么要这么做和业内方案相比有什么好处和坏处如何权衡的
事中
少调整尽可能少的技术方案需要调整 否则无法完成开发任务
事后
少补丁尽可能少的 bug 或者遗漏可扩展 可复用相对简单的改动就能支持新增需求类似场景可复用不需要重复开发
一篇好的技术方案可以贯穿整个研发的生命周期并且能起到很好的指导意义就如同写小说之前作者必须出一个大纲的逻辑是一致的。
如何写好一篇好的技术方案
那么如何写出一篇好的技术方案呢下面列举出笔者认为应该做到的一些点。
清晰的目标
一份技术文档需要有一个清晰的目标业务需求建议自己总结而不是 Copy from PRD技术自发的那肯定得自己总结那目标怎么来的呢是从需求里转化过来的。那么如何将对应的需求转化为一个清晰的目标我认为最重要的是要尽量定义一个可衡量的标准。需求的种类一般来说就两种分别是
1.产品类需求——业务方 or 产品方发起提给技术包括但不限于以下几种
页面交互能提升多少的运营操作效率多少 PV、UV 这种可量化的数字业务 SOP 调整带来的业务价值是什么是能降多少本还是提升多少时效数据订正订正能解决什么问题防止多少钱未结算又或者是防止多少客诉
2.技术类需求——技术自发提出包括但不限于以下几种
性能优化优化多少20%、30% 还是 50%数据隔离隔离的范围是什么涉及多少张表多少数据可以减少当前的什么问题减少多少各种小工具没有小工具之前是什么样有之后是什么样可以带来什么好处研发效能提升提升多少有没有可以量化的指标而不是为了做而做。
在众多的需求当中还有一些是我们要去辨别的伪需求——不是用户真正想要的需求如用户想要将一个飞机改造成火箭但是产品可能提过来的仅仅是把飞机的两个翅膀砍掉那么砍掉翅膀就能变成火箭了吗明显不能所以这种需求一定要注意鉴别。
大纲图
有句话叫“不谋全局者不足谋一域”在技术方案中我想也是如此。在一个技术方案中一个大纲图是不可或缺的 有的人叫它技术架构图有的人叫它数据流转图这都不重要重要的是我们能从这张图中看到整体的脉络那么这张图需要有哪几个要点呢
图不用很细比如加工比较复杂我们可以简单写**加工但是要能看到全貌具体的每个模块如果需要展开的那么在对应的详细设计中体现即可在这里我们关注的是整体接口如有归属不同的应用要标明数据存储介质不同要标明数据流转的箭头要清晰明确数据加工计算的输入和输出要体现同时要体现加工的运行环境比如到底是 odps 计算还是内存计算内存计算的话是在那个应用。
模型设计
讲到数据模型设计E-R 图是必不可少的E-R 图应该包含以下信息
每个领域对象如果要持久化都有表来存储。我们设计完 ER 图的时候应该根据这条原则做一番检查避免漏掉一些表。在大型项目中漏掉表是很常见的事情应尽量避免。领域对象之间的关系如果要持久化都要在表结构中体现。这种体现可能是 code 字段可能是外键可能是中间表。我们设计完 ER 图的时候也应该根据这条原则做一番检查避免漏掉一些关系。在大型项目中漏掉关系更是司空见惯应尽量避免。清晰定义的表名。设计 ER 图的时候就要设计出清晰定义的表名。清晰定义的表名可以帮助大家理解 ER 图可以帮助大家映射回领域对象及其关系。在后续的设计和实施中将沿用这个表名。清晰定义的字段名、字段类型、字段长度和枚举值。很多同学容易忽略这点他们往往清晰定义了表名却没有重视表的字段。认真去做的时候会发现这里面有很多工作。例如字段名是否合适用什么类型好字段长度多少合适是否有枚举值等等都需要一一斟酌。如果这点做好了在实施的时候可以避免很多麻烦甚至避免返工。
对外依赖提前确认
技术方案 1需要依赖缓存、分布式调度中间件、消费外部的消息但是没有把对应的中间件使用方式、数据格式贴出来。 技术方案 2需要依赖缓存、分布式调度中间件、消费外部的消息将缓存接入的方法 对应的缓存 key-value 设计写清楚将分布式调度中间件接入所需要准备的依赖项梳理好将外销消息对应的 topic 和数据格式列清楚。 两个方案对比好坏其实很明显。如果一开始我们在技术方案里面将外部依赖确定好那么我们在开发的时候就一马平川反之如果外部依赖都不确定的情况下就进入到开发那么返工的概率将大大增加从而降低我们的工作效率。 那么对外的依赖有哪些以及我们应该要确认什么信息呢下面列举了一些常见的依赖情况
外部 hsf 依赖需要确认对应 hsf 接口的类、方法、version以及二方包也可使用泛化调用外部消息依赖需要确认消息的 topic、数据格式分布式调度、缓存等中间件当前应用是否接入过该中间件未接入需要去到官网确认接入文档接入的话需要确认是否可以复用接入逻辑。
内部前后模块依赖 层次结构
模块依赖层次从高到低分为
领域依赖如交易依赖商品应用依赖如 cntcp 应用依赖 cngfc 应用接口依赖如滚存看板查询接口依赖于锁接口 渠道集接口
我们举接口依赖的例子来看一共三个接口分别是滚存看板查询接口、锁接口、渠道集接口滚存看板查询接口依赖于锁接口和渠道集接口。 技术方案 1 目录层次滚存看板查询接口、锁接口、渠道集接口 技术方案 2 目录层次锁接口、渠道集接口、滚存看板查询接口。 很明显技术方案 2 是更加合理的A 依赖于 B 那么 B 应该先做。 我们在写技术方案的时候要考虑什么应该在前什么应该在后而不是想一步写一步。要有一个清晰、有序的结构不然别人看起来就会是杂乱无章的。
一个模块里面应该有啥
下面列出一个技术方案的模块里面应该要写哪些东西供参考
1、具体的接口定义 要求实现一个飞机运力合同查询接口入参为运力大区 技术方案 1
入参
{
area: 南美
}
出参:
{
date: ***
}
技术方案 2
方法名CapacityService.queryPlan
入参
{
cnArea: 南美
}
出参:
{
date: ***
}
技术方案 2 是更好的为什么测试、前端 、后续要接手该接口的人都能够一下子找到你的接口并清楚知道输入输出是什么。另外1 和 2 的入参一个 area 一个 cnArea那么到底哪个更对呢这里由于系统中在用的都是 cnArea固沿用 cnArea 是对的一致性减小沟通成本。
这里总结对接口定义有几点要求 完整的类和方法名
入参字段如果系统中已有那便沿用如果没有那么英文的描述需要准确可同产品业务商榷
出参字段要求同入参
2、详细的时序图 要求实现一个学生信息查询接口。 技术方案 1写出查询结果中执行的相关步骤。
step1. 入参校验
step2. 查询A表
step3. 对A标返回结果做校验
step4. 查询B表
······
技术方案 2在 1 的基础上使用时序图表达出来。
推荐使用技术方案 2好处是尽管内容相同但是时序图能够更直观地看到层次、数据流转等信息。
除了以上比较基础的 2 点我觉得的还有一些要点
数据加工的详细图如有——同样推荐用图的形式可以更直观消息设计如有明确消息生产方、消费方、tps、数据结构自测用例推荐比较重要的功能点构造一些自测用例
······
技术选型分析
要求实现一个定时任务定期将过期的数据删除。 技术方案 1使用 spring 自带的定时器进行数据清除。 技术方案 2使用分布式调度中间件如 schedulerx进行定时过期数据清除。
乍一看好像都能实现但仔细对比两个实现方式之后我认为大部分人还是会选择技术方案 2为什么下面列出一些在选择技术方案时考虑的点。 安全生产
安全生产包括几个部分包括且不限于下面几个部分
监控对账灰度方案数据隔离兼容性评估发布流程
我们举一个例子。
需求在消费者收货成功时触发对商家的结算。 技术方案 1写了一堆如何触发结算、如何更好地支持后续的可扩展性 技术方案 2写的方案可扩展性没有技术方案 1 高但是做好了未触发结算的监控、触发结算之后的对账并设计好了对应的报表防止出现资损。 其实这也是我们在技术方案中可能会忽略的一点——埋头于代码结构如何如何的好但是有些东西其实是要比单纯的代码更重要。就比如风险控制完备的监控、不可缺少的对账是保障公司资金安全更是保障我们自己绩效的工具此处应有表情。
那么对于监控、对账的具体要求是什么呢我认为有以下几点
监控
监控目标写清楚监控的是什么内容监控点如通过打印日志监控那么日志打印在哪个类的哪个方法监控触发是通过 sunfire 采集触发还是其它如果是 sunfire 采集最好能把监控项地址贴出来监控订阅人监控告警需要的订阅人监控触发后的解决方法如果发生异常该如何解决如手工触发结算
对账
对账目标写清楚对账是为什么对账方式写清楚是怎么对账的如通过 odps 天级定时任务履行单上的关务资源 code 和日志表中关务 cp 回传报文的关务资源 code 对比要一致不一致的形成某个数据集通过锦衣卫-资损风险平台配置对账告警订阅人对账异常之后的解决办法
还有其它几个部分也补充说一下
灰度方案包括但不限于
多方前置准备灰度切流开关设计灰度切流节奏异常应对
向前兼容性包括但不限于
接口的向前兼容尤其是对外的接口数据结构的向前兼容如不能随意改变字段的存储类型和格式
环境隔离
如有租户隔离 预发线上隔离的情况需要考虑数据
发布流程包括但不限于
发布计划检查项列表发布流量监控
作者 | 忠武
原文链接
本文为阿里云原创内容未经允许不得转载
