新手村of技术方案准备记录

就近期准备一次项目所得，关于技术方案设计和技术评审方面的一些思考（此次技术方案并不复杂，为已有链路上的新分支，无涉及到新项目/模块的建设）

什么是好的技术方案 如何写好技术方案，ATA中也有相关优秀的文章，此文则仅作为自己的一次实践后的总结和想法

技术方案要点

• 团队中一般都有相关规范/模版，如果是已经有过经验的or对项目熟悉的同学，则是按需填充即可；反观对于新同学来说，规范、背景业务了解，现有系统交互、和相关改动... 准备的过程相对来说会相对久一些，以下则是自己的一些想法

1. 梳理好背景&目标

• 背景个人觉得是必不可少的；背景介绍已拟定了前提，并且讲此次的改动也置入了某个场景，对于读者来说，更好的理解你在干什么，为什么要干这个事情的一个动机
• 目标倒是可以区分视角来看；业务/技术；业务侧可能是一个数值化的预期结果，而技术侧的更多的是实现XXX能力、提供XXX工具用来提高人效、或者技改场景下使得项目结构更加整洁、相似业务场景接入的效率提升

讲完背景和目标之后，对于读者就会有一个大体的把握（干的是啥、为什么要干）

2. 主要部分

此部分是要讲述好-你准备来如何着手实现xxx功能了，讲述部分可由大至小，由远至近

1. 前面最好有个大图梗概，不必太细节；需说明出你系统/模块所处的位置，你的上游引用、你的下游依赖 最好都有标明，各个系统/模块的依赖关系也需用箭头加以示意；其次需要highlight你此次的改动部分/范围或者交互方式（做到这个图可以知道你此次的改动范围如何，受影响方会有谁）

表达完大体改动，接下来较为细一点的就是你此次改动的链路，（如果在涉及到多部分的改动/实现的case下，则最好附以表格形式列好此次的改动，并将重改/大改/核心的部分提前）

1. 整体链路逻辑，时序图是个较为常用的方式，既能明确你此次实现步骤其次可清楚此次的参与者；（如果是新流程/新业务/新项目，还需补充系统方面的设计）在讲述这块的同时，可以以其他颜色标明你此次新增/补充的链路逻辑，分支场景的处理和参与者的交互方式

后面则是更细的接口协议/内部模型设计/新增消息..（仅表达改动部分即可）

1. 接口/模型设计

1. 1. 如果是新接口则需列接口设计（方法出入参等信息）-最好是可以给到demo，如若是已有接口，则也需要列出此次改动，并确定好新接口相关协议
   2. 内部模型(DB实体/值对象...)的改动同样需要区分新增/修改，且将改动后的原型贴出（E-R图/类代码），不仅仅作为实现记录，也可让参与评审人感知此次改动的具体细节
   3. 此外关于与中间件相关的交互，也不要忘记，需要补充相关信息，比如消息体模型/topic/tag... ，Diamond的key值、其模型设计，所属/推送单元等...

1. 具体链路实现加以补充，前面的讲述过多在于你在什么时候什么业务场景下去实现你的新逻辑，而在此部分可以贴代码或者使用更加细步骤的时序加以补充，可以明确改动点、改动范围和逻辑
2. 功能点罗列，此处旨在分工/功能点的实现-可补充预计具体投入人日，通常以表格来记录（记得总结下总预估投入人日为XXX，可注明是否包含联调人日）
3. 稳定性梳理，该部分主要是预案方面处理

1. 1. 可以列风险具体case，及应对降级逻辑（兜底组件/友好提示...）

3. 排期节奏

这一part一般在技术方案讲述完后，给到大家一个里程碑，结合自己预估人日，明确开发/提测/上线时间，若有时间节点待定，也需留档说明。留以todo后续补充

4. 上线计划

这个可结合技术方案后续进行梳理，明确好发布顺序、（是否前后依赖）依赖包版本、前置配置...

至此，技术方案的主要部分就已经构建好了，可以再回过头来整体看看是否有讲清楚为何要开始及如何去实现，实现过程中的保障。

其他

此部分则是对于技术方案文档的补充，比如记录

• 文档变更记录--作为每次变更记录缘由 其次也可记录会议纪要
• 项目成员 - 明确业务/测试/开发
• 项目选型 - 这个则是关于取舍的优劣分析过程