开发之痛-变更
在日复一日的项目开发中，最常见的又最不可避免的就是变更，从页面、流程到数据结构都可能会涉及，除了常见的fighting，本着不能改变就适应，发挥适者生存的能力，今天讨论下，怎么通过开发一种工具，来减轻变更带给我们的痛苦。
流程变更自我救赎之流程编排
市场其实有很多流程编排的系统，这也不是新鲜玩意，最早被大家熟悉应该是OA中的办公流程配置，不同流程编排系统有不同侧重，但对于普通的系统来说，引入一个流程编排系统，无疑是杀鸡用牛刀，况且还有采购成本、接入成本等等。对于大多数开发者而言，流程编排的难度不是后端实现，而是前端界面（个人浅见：因为做业务流程的一般是后端，对前端不熟），那如果有个前端页面，支持通过json扩展流程节点，通过json扩展节点的属性配置，然后生成编排后的标准json，后端基于标准json进行解释执行，岂不爽哉？
- 可视化流程编排：
- 转换成标准的steps：
{
"steps": [
{
"type": "start",
"id": "009c0914-4403-4be5-a4bf-a0c7c02be9b8",
"name": "start",
"nextStepId": "0a81d7f4-0b28-4a31-b98d-a38317e8c6ce"
},
{
"type": "switch",
"id": "0a81d7f4-0b28-4a31-b98d-a38317e8c6ce",
"name": "",
"branches": [
{
"when": "",
"nextStepId": "4ca0e8e9-0d67-4547-b0ae-7f8982aa5aa3"
},
{
"when": "",
"nextStepId": "2f218ff9-748d-427f-a18f-d90dd0b516de"
}
]
},
{
"type": "js",
"id": "4ca0e8e9-0d67-4547-b0ae-7f8982aa5aa3",
"name": "JS代码块",
"nextStepId": "9b20bd97-e7e1-4c4a-8846-7accdbf0318a"
},
{
"type": "process",
"id": "9b20bd97-e7e1-4c4a-8846-7accdbf0318a",
"name": "子流程",
"nextStepId": "551f1e5b-349e-41c5-badb-2bb6493badf1"
},
{
"type": "end",
"id": "551f1e5b-349e-41c5-badb-2bb6493badf1",
"name": "end"
},
{
"type": "http",
"id": "2f218ff9-748d-427f-a18f-d90dd0b516de",
"name": "http请求",
"nextStepId": "551f1e5b-349e-41c5-badb-2bb6493badf1"
},
{
"type": "end",
"id": "551f1e5b-349e-41c5-badb-2bb6493badf1",
"name": "end"
}
],
}
我先开发了一个救了我自己
在配合实现一个任务协同中间件的项目中，因为POC阶段的不确定性，接口、参数、界面都是摸索着前进，并且存在大量的yaml配置文件需要在使用时配置，开发页面本身，和在测试及使用时的配置文件配置，都存在较多的不确定性和上手门槛。 为了不让自己陷入重复劳动，开发了两个低代码工具：
- 基于json的页面开发与运行工具(封装了amis)
- 基于json和js的流程编排（x6+x-render）
分别承担了任务调试、日志查询等页面开发，以及简化中间件配置，通过可视化生成配置文件的功能。
值得一提的是，因为流程节点通过配置很容易扩展，我们可以根据使用场景实时的、精准的随时扩展业务流程节点，使我们的用户更好理解，比如我们有Thrift调用、全局异常处理等特殊处理，就直接扩展了节点和配置属性，很直观的在编排中显示了出来，后台只需根据转换后的steps进行解析处理。
有空再与大家分享一下另外一个基于json的页面开发工具。
