关于技术方案

不知道大家在项目过程中写过技术方案么，对于项目中迭代比较大影响范围比较大情况。可以由技术主导人在编码之前，先出个技术方案然后在开始编码。
出技术方案的好处是：

1. 在编码之前对此次改动有个全局的思考，知悉这次改动的边界和难点
2. 技术方案中把具体实现逻辑和难点做了解释，具体实现人员可以通过技术方案就知道在项目中怎么实现。
3. 如果是多人合作，可以在组内达到共识。
   下面贴一个我们项目组技术方案的模板/原则。欢迎大家讨论一下

整体的原则：

1. 不能脱离业务：脱离业务的架构都是耍流氓

2. 方案简单易实现，容易落地：方案一定要简单，简单，简单（重要的事情说三遍）

一. 背景

主要说明为什么要做这次技术方案，解决什么问题

二. 现状

针对修改点，目前的现状是什么，尽量的写涉及的细节，包括但不限于，数据实体、数据流程、技术方案等，方便评审者对现状有所了解

三. 技术实现

技术方案的实现细节，说明技术方案如何实现以及如何能解决现有问题，尽量详细，有选择的包括以下几点：

1. 解决问题的技术方案

• 技术架构图
• 业务流程图
• 实体ER图
• 部署架构图

2. 设计要点：强调方案设计过程中技术要点及难点

3. 技术方案的可行性分析

• 数据量：要对现有和未来一段时间的数据量有所感知，并且新的方案在预估的数据量下不会有性能问题
• 性能：原则上，新的方案一定要比老的方案性能好
• 简单：设计要尽可能的简单易懂

4. 如果需要新引入新的技术，需要有技术选型方案以及主流的技术或者框架对比

5. 如果有多个技术技术方案，对比各个实现方案的优缺点，并给出推荐的方案

6. 如果需要他人或系统支持：

• 指明需要别人或系统支持什么，特别指出
• 什么时候需要提供支持

7. 兼容性考虑：新技术或者优化，不能直接全量上线，要考虑回滚或者异常处理

• 是否需要考虑试点，局部试用
• 是否考虑增加开关，一旦出问题就关闭
• 是否需要做数据验证，防止数据不一致

四. 影响范围

技术方案对业务或者系统影响，包括不限于：

1. 修改是否影响上下游系统（内部和外部）的调用，是否会感知

2. 修改影响的接口（内部和外部）

3. 对代码修改的范围

4. 其他

五. 解决成本

实现技术方案需要增加的成本：

1. 存储

2. 引入新的云服务

3. 增加机器资源

4. 其他成本

本作品采用《CC 协议》，转载必须注明作者和本文链接