开发 -- 需求流程

一、场景设计

---

1. 思维角度

1) 完整：
时序图，根据完整的业务流程将业务通过时序串联起来。
创建  -- 执行 -- 结束（失败/成功） -- 清理 -- 回滚

2) 反面：
每想到一种客户场景，冷静下来，不要沾沾自喜。
场景的反面流程是否想到，订购就要想到取消，升级就要想到回滚。

3) 扩展：
每解决了一类错误，冷静下来，不要盲目结束。
每种错误都是一类问题，别的开发分支是否有这样的问题。

2. 属性关系抽象和识别：

1) 理解业务，从业务中分析出对象和流程

2）对象梳理
对象之间存在各种关系，依赖，共存，互斥等等，可以借助ER图进行识别和梳理
如：参数下发的需求 -- 细粒度的参数的更新关系记录在status里（etcd表中），pod依赖status里的数据就可以。后续参数的更新以status里的数据为准即可。

3）流程梳理
流程之间可能存在多种方案，因此需要设计多套对象之间的流程流转，最终选择最好的。
如：Operator升级 -- webhook的技术使用只是其中一个方面，不同版本的升级内容单独放在各自的版本更新维护，还是放到一个版本里统一维护。
都是需要根据实际情况进行分析和抉择。

1）层级关系
- 通过现实生活对应确定关系
- 通过推理确定
    action 套 [local/remote] ，execute新增，需要通知每一个action修改switch case，新增此类方式。
    local/remote 套 [action] ，action新增，只需要注册到对应的类中。

2）粒度关系
集群 -- 组件 --  租户 -- 分片 -- 机房 -- team -- ip

3. 设计能力：

厉害的人，能够把所有线串起来推理，接近于100%的现实。
目前的我，需要依赖大量的经验来支撑，而推理能力往往会有遗漏、不符合真实模型，需要很大提升。

1) 调研涉及历史的业务
必须满足

2）满足现有需求的要求
必须满足

3）未来可能得扩展要求
未来展望实现的可能性 （>60%的需要考虑保留接口）

4. 方案选择：

4.1  功能内聚
1） 总控和组件 -- 上层做调度，不关心细节； 下层做执行，不关心调度
2） 业务  -- 按功能内聚

4.2 算法复杂度
1）单机串行 -- 并发
2）多机串行 -- mapreduce
3）业务 -- 流程优化

5. 积累开发规范

1) 发现设计过程中的规范，及时积累。传递给其他同事。

二、 问题转化

---

1. 问题对象识别

1） 是哪一种数据结构？ 
线性、树形、图

2. 问题对象难点分析

1）读多写少，还是读少写多
2） 串行，还是并发

3. 常用算法解决

积累，见具体文章

附录：

### 1. 需求分析
- [ ] 背景了解

- [ ] **场景初步梳理**   （持续整个周期：业务场景，异常场景，并发场景，高可用场景）
场景分析：
 - [ ] 操作粒度：管理节点、租户、分片、机房、team、容器
 - [ ] 操作动作：安装、水平扩缩容、纵向扩缩容、升级 
 - [ ] 涉及相关业务场景：
  - [ ] 容器化：自启动，重启等
  - [ ] 数据库：水位，主备，rdb刷sql等
场景要求：
 - [ ] 流程合理性，流程业务全覆盖
 - [ ] checkList 梳理
 - [ ] 异常场景
 - [ ] 并发场景
 - [ ] 高可用场景

注意点： 场景多是π型结构，不能因为一个纵向难点，忽略了其他横向的场景。【盲点】

- [ ] 技术穿刺
 - [ ] 技术可行性验证（结合场景梳理） （函数在ipv4 和 ipv6的验证）
 - [ ] 其他竞品
 - [ ] 官方文档 或者 来源论文
 - [ ] 结合项目
	
### 2. 概要设计
- [ ] checkList 
- [ ] 流程设计
	- [ ]  组件交互**场景梳理**   
- [ ] 组件功能要求
- [ ] 场景测试用例（开发）
- [ ] **全流程业务流程图 （再简单的需求，也需要！包含所有的场景和组件）**

### 3. 详细设计
- [ ] checkList 
- [ ] 对接组件接口设计
- [ ] 结构体设计 && 类设计
- [ ] 函数设计&&流程图设计
 - [ ] 代码是否满足**场景梳理**  && 新增场景
	
### 4. 代码开发
- [ ] checkList 
- [ ] 代码开发（精准的代码才是效率的关键，精准取决于整体流程 + 代码能力）
 - [ ] 不许copy（避免思维固化）
 - [ ] 伪代码只能写思路，不能写代码（避免思维固化）
 - [ ]  每一行代码，需要通读涉及到的场景 和 代码
 - [ ]  每一行代码，要想：对吗？全吗？反面呢？异常呢？是否影响已有功能？
- [ ] UT
 - [ ] 无法写UT ，每一行代码必须运行到。【必须】
- [ ] 代码走查
- [ ] checkList + 测试用例

### 5. showcase 
 - [ ] 登记showcase记录
 - [ ] 提交showcase记录的修改
 - [ ] checkList + 测试用例   (慎始如终) 

---

常见设计问题

1. 性格是比较谨慎，常常需要边开发边调整详细设计，开发七八成之后详细设计才会比较靠谱。但是如果一开始只做详细设计，一方面是设计不够全面，二是考验心态，容易心慌，担心开发阶段调整，导致全面翻盘。但是公司要求，详设阶段就把整体思路确定，将开发的风险提前暴露，避免开发返工。
   如果调整思路，满足详设的要求同时克服自己的恐惧心理？

2. 拿到需求，穿刺了很多项目。结果详设的时候，基础模型越想越复杂，涉及原始代码改动越改越多，导致开发进度停滞不前怎么办？

3. 架构优化 或者 重构的时候，此类任务很考验经验和脑力。如何将之流程化？

4. 如何判断一个项目的难易程度 和 复杂程度，首先项目能不能做，其次项目做多久，合理规划项目的实际落地时间？