工作的流程
整体流程：了解业务-梳理流程-归纳并抽象--抽出一套通用流程。
这里的通用流程是在完整性下可以伸缩性的适配业务的需要。而对于超出通用流程的事务。为了减少复杂度或考虑到特殊业务对通用流程的侵入性，我们会单独改造 一个适配性的流程来解决。
目标和原则
- 减少离散性的代码冗余
- 降低维护、排错成本
- 流程适配灵活性
- 流程健壮性
- 流程容错性
关于抽象
结构化的归纳和抽象
- 整体的归纳，去抽象出各种角色服务的公共资源的依赖
问题点和解决
问题：抽出公共资源依赖，做为一个基依赖被反复调用，有可能某些角色的动作执行时也会引用到或者反复引用，这种情况有几种解决方案：
- 对于反复引用有幂等性来实现容错
- 对于非相关性要避开引用则可以加条件过滤掉。
流程的归纳和抽象
- 流程上抽象上不同角色服务的流程共性，并通过逻辑判断支持灵活的适配流程
问题点和解决方案
问题： 服务角色流程不一致或具有侵入性，A事务的自动化脚本，跨入B事务的流程。比如 A角色的服务的流程在更新预准备动作处理流程：解压包到临时目录，临时目录再同步到预准备目录。 更新流程： 从预准备目录再正式工作目录
但实际上我看到这个流程在不同服务间有点混乱，有些是直接解压到预准备目录，有些甚至就直接解压到正式工作目录。
这个就会带来几个问题：
- 是流程不一致，难以抽出共性。
- 流程混乱，整个管理成本增加，最好是标准化
- 流程具有侵入性，预准备流程跟正式更新流程侵入了。虽然是不同服务，但如果抽象出逻辑判断兼容这所有流程，万一一个变量配错，整个线上业务就会出现问题。
跨系统的其它问题
跨系统的数据结构问题
- 曾要有一个需求研发指明数据结构从系统A传递到我这边的接口B只支持字符类型，而整体的流程是系统A -- 接口B --- 自动化脚本C
于是从这个流程来看的话，如果数据结构到后端必须是数字类型或逻辑型，那就存在几个问题：
- 技术债推给后面几层
- 数据结构前后不一致
- 增加维护和可读成本
但是如果是后端默认不支持各种各样的数据类型，那只能接受这些缺点。
跨语言协同的问题
- 在完成一个项目时，任务间往往有依赖需要协同。那如果语言特性本身就支持，那最好不过，这可以大大降低技术成本，提高可维护性。比如go语言的chanel和goroutine.但是我们实际项目中也遇到是跨脚本，甚至跨语言的结合完成一个系统任务。这时候可能就用不了语言自带的特性，而是借助缓存或其它一致性的服务来完成任务间的协同。
最后总结
- 流程尽量统一标准化
- 数据结构跨系统或接口传递一致性，避免技术债向后推
- 充分考虑语言的特性来降低技术和维护成本
- 结构上抽出公共资源依赖同时考虑排它性和反复执行的容错性
