简介：近期作者在写某个我的项目的技术计划时，来来回回批改了许多版，很是苦恼。于是，将本人之前写的和他人写的技术计划都翻出来看了几遍，产生了一些思考，分享给大家。
编辑
切换为居中
增加图片正文，不超过 140 字（可选）
作者 | 忠武
起源 | 阿里开发者公众号
近期在写某个我的项目的技术计划时，来来回回批改了许多版，很是苦恼。于是，将本人之前写的和他人写的技术计划都翻出来看了几遍，产生了一些思考，分享给大家。
咱们为什么须要写技术计划？总结下来无非是几点，从不同人的视角来看：
产品：验证技术计划是否可能 match 上产品计划
测试：验证技术计划对测试计划是否有足够 & 精确的输出
共事 & leader：参加技术计划评审，验证技术计划的合理性
新人 (不单单指新同学也指新接触这一块的同学)：拿到技术计划能够很快对某一块的事件熟悉起来
什么样的技术计划是一个好的技术计划
咱们都晓得技术计划是领导具体开发工作的，能够别离从开发的事先、事中、事起初探讨这个问题。
事先
明确的指标：整个技术计划要达成什么目标
低沟通老本：产品测试能从技术计划上获取足够的输出，不须要重复找你确认
技术选型思考：为什么要这么做？和业内计划相比有什么益处和害处，如何衡量的
事中
少调整：尽可能少的技术计划须要调整，否则无奈实现开发工作
预先
少补丁：尽可能少的 bug 或者脱漏
可扩大 & 可复用：绝对简略的改变就能反对新增需要，相似场景可复用不须要反复开发
一篇好的技术计划能够贯通整个研发的生命周期，并且能起到很好的指导意义，就如同写小说之前作者必须出一个纲要的逻辑是统一的。
如何写好一篇好的技术计划
那么，如何写出一篇好的技术计划呢？上面列举出笔者认为应该做到的一些点。
清晰的指标
一份技术文档须要有一个清晰的指标（业务需要倡议本人总结而不是 Copy from PRD，技术自发的那必定得本人总结），那指标怎么来的呢？是从需要里转化过去的。那么，如何将对应的需要转化为一个清晰的指标？我认为最重要的是要尽量定义一个可掂量的规范。需要的品种一般来说就两种，别离是：
1. 产品类需要——业务方 or 产品方发动提给技术，包含但不限于以下几种：
页面交互：能晋升多少的经营操作效率，多少 PV、UV 这种可量化的数字？
业务 SOP 调整：带来的业务价值是什么？是能降多少本还是晋升多少时效？
数据勘误：勘误能解决什么问题？避免多少钱未结算？又或者是避免多少客诉？
2. 技术类需要——技术自发提出，包含但不限于以下几种：
性能优化：优化多少？20%、30% 还是 50%？
数据隔离：隔离的范畴是什么，波及多少张表，多少数据？能够缩小以后的什么问题？缩小多少？
各种小工具：没有小工具之前是什么样？有之后是什么样？能够带来什么益处？
研发效力晋升：晋升多少？有没有能够量化的指标？而不是为了做而做。
在泛滥的需要当中还有一些是咱们要去分别的伪需要——不是用户真正想要的需要，如用户想要将一个飞机革新成火箭，然而产品可能提过来的仅仅是把飞机的两个翅膀砍掉，那么砍掉翅膀就能变成火箭了吗？显著不能，所以这种需要肯定要留神甄别。
纲要图
有句话叫“不谋全局者有余谋一域”，在技术计划中我想也是如此。在一个技术计划中，一个纲要图是不可或缺的，有的人叫它技术架构图，有的人叫它数据流转图，这都不重要，重要的是咱们能从这张图中看到整体的脉络，那么这张图须要有哪几个要点呢？
图不必很细（比方加工比较复杂咱们能够简略写 ** 加工），然而要能看到全貌，具体的每个模块如果须要开展的，那么在对应的具体设计中体现即可，在这里咱们关注的是整体；
接口如有归属不同的利用要表明；
数据存储介质不同要表明；
数据流转的箭头要清晰明确；
数据加工计算的输出和输入要体现，同时要体现加工的运行环境（比方到底是 odps 计算还是内存计算，内存计算的话是在那个利用）。
编辑
切换为居中
增加图片正文，不超过 140 字（可选）
纲要图的逻辑示意参考
模型设计
讲到数据模型设计，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，为什么？上面列出一些在抉择技术计划时思考的点。
编辑
切换为居中
增加图片正文，不超过 140 字（可选）
平安生产
平安生产包含几个局部，包含且不限于上面几个局部
监控
对账
灰度计划
数据隔离
兼容性评估
公布流程
咱们举一个例子。
需要：在消费者收货胜利时触发对商家的结算。
技术计划 1：，写了一堆如何触发结算、如何更好地反对后续的可扩展性；
技术计划 2：，写的计划可扩展性没有技术计划 1 高，然而做好了未触发结算的监控、触发结算之后的对账，并设计好了对应的报表防止出现资损。
其实这也是咱们在技术计划中可能会疏忽的一点——埋头于代码构造如何如何的好，然而有些货色其实是要比单纯的代码更重要。就比方危险管制，齐备的监控、不可短少的对账是保障公司资金平安，更是保障咱们本人绩效的工具（此处应有表情）。
那么对于监控、对账的具体要求是什么呢？我认为有以下几点：
监控：
监控指标：写分明监控的是什么内容
监控点：如通过打印日志监控，那么日志打印在哪个类的哪个办法
监控触发：是通过 sunfire 采集触发还是其它，如果是 sunfire 采集最好能把监控项地址贴出来
监控订阅人：监控告警须要的订阅人
监控触发后的解决办法：如果产生异样该如何解决？如手工触发结算
对账：
对账指标：写分明对账是为什么
对账形式：写分明是怎么对账的（如通过 odps 天级定时工作，履行单上的关务资源 code 和日志表中关务 cp 回传报文的关务资源 code 比照要统一，不统一的造成某个数据集，通过锦衣卫 - 资损危险平台配置）
对账告警订阅人
对账异样之后的解决办法
还有其它几个局部也补充说一下：
灰度计划，包含但不限于：
多方前置筹备
灰度切流开关设计
灰度切流节奏
异样应答
向前兼容性，包含但不限于：
接口的向前兼容：尤其是对外的接口
数据结构的向前兼容：如不能随便扭转字段的存储类型和格局
环境隔离：
如有租户隔离 & 预发线上隔离的状况须要思考数据
公布流程，包含但不限于：
公布打算
查看项列表
公布流量监控
数据分析系统之数据管理与数据仓库
点击这里，查看详情。
原文链接：http://click.aliyun.com/m/100…
本文为阿里云原创内容，未经容许不得转载”。