精读《低代码逻辑编排》

[ascoders]

本周精读对文章是 How To Create Your First Flow in Node-RED

Node-RED 是比较有代表性的低代码流程编排工具，这次我们介绍一下其功能，并结合我自己理解谈谈对流程编排的看法。

---

精读《低代码逻辑编排》

[atian25]

对这个的可读性和可维护性存疑

[ascoders]

还有更复杂的案例：

[ascoders]

只要命名合理，拆分粒度合理，可以看作可视化类图，我觉得至少流程一眼看下来比较清晰，不像代码要跳来跳去的看。

[atian25]

这也是我一直对 可视化编排 系统存疑的地方，之前蚂蚁内部有过很多个编排系统，都是业务线同学搞起来的，一直都是死了一个又来一个，但一直没有给我一个很好的答案：

• 编排系统面向的用户群体是怎么样的？他们的特征是怎么样的？
• 简单的逻辑太简单，复杂的逻辑太复杂，如何解决可维护性问题？

我个人是认为他们真实的诉求不是可视化编排，而是『快速发布能力』，这个其实基于 Serverless 搞轻量化的代码研发，pro code 也是可以的满足的，只要做到足够的『轻研发 + 免运维』。

[atian25]

代码逻辑是可以考虑代码分析和约定的方式，来可视化出来，侧重于 『读』，而不一定是 『写』

[ascoders]

认同免运维目的性的观点，但代码可视化分析太难了，参考可视化搭建 UI 和 HTML 代码哪个更好维护。

UI 搭建的区块天然有约束，导致整个平台统一性强（注入统一功能），易于编排（符合平台规则）。如果从 HTML 代码反生成搭建配置，必然造成逻辑丢失，或者还原问题，这都是代码模式太灵活导致的后果，而如果恰恰业务不需要这样的灵活度，仅因为随机性，就采取了非常规写法，也无法避免。

UI 编排的结论也许能部分推到到逻辑编排领域，本质上可视化编排是为了限制某些灵活度，缩小理解成本，和自己造一个 DSL 用 JSON 方式描述配置无本质差别。

所以如果业务场景适合用可视化已有的组件编排，应该更容易维护，在大家都理解逻辑编排组件上下文的前提下。更复杂的需求可以切换到 Pro Code 模式，不必追求所有场景都用逻辑编排完成。

[atian25]

代码可视化分析太难了

我是觉得通过可视化来看代码的诉求不是很强，太简单的场景，写代码和拖拽没啥区别，太复杂的场景，如上面可视化出来的图的阅读性也不见得多少。

[baxtergu]

尝试过用 DataV 的 蓝图编辑器 做过复杂交互的可视化开发，与这个很类似。最终尝试失败后转纯代码开发，当业务需求越来越复杂以后，Low Code 开发成本 >> Pro Code。但是很多需求其实是从简单不断变复杂的，很难在一开始就进行甄别。无论是面向开发人员还是设计人员，最终的可视化逻辑展现都是几乎不可读的，维护和修改成本更高。

一般复杂业务的可视化表达都是网状的，如果某一个需求的逻辑可以抽象成一个有向线性的表达的话，其实 pro code 开发效率并不低。就目前阶段来看，Low Code 提效主要体现在轻量级的重复需求，一般是表单类应用。

基于我个人视角对使用 Low Code 的最大顾虑是：能否能让投入在 Low Code 上的工作能够最大程度在转 Pro Code 后保留，避免浪费。Low Code 的终极形态一定不会是现在这样，应该还有更多的想象空间。

个人粗浅看法，欢迎斧正

[dengnan123]

尝试过用 DataV 的 蓝图编辑器 做过复杂交互的可视化开发，与这个很类似。最终尝试失败后转纯代码开发，当业务需求越来越复杂以后，Low Code 开发成本 >> Pro Code。但是很多需求其实是从简单不断变复杂的，很难在一开始就进行甄别。无论是面向开发人员还是设计人员，最终的可视化逻辑展现都是几乎不可读的，维护和修改成本更高。

这个需要你把需求屡的非常清楚，并且对平台的交互机制有很深的理解，当然如果平台对交互这块没过多考虑的话，那做起来确实麻烦

[ascoders]

其实需求复杂后，逻辑编排导出可读的代码继续维护也是一条路。至于代码风格和语言可以自由选择，比如支持导出 js、ts 的，react、vue、angular 框架的，function or class 风格的，css modules or css in js 的。服务端支持导出 node or java 语言的。

[atian25]

像 GitHub Actions 类似的场景，感觉如果提供可视化编排能力还是不错的：

• pipeline 主流程通过可视化方式来编排，一般也不会太复杂，几十个节点内，分支也不会太多。
• 部分节点提供在线编辑器来直接编写 pro code 作为处理逻辑。（可以适当要求用户提供输入输出来作为测试）
• 整个 pipeline 可以作为一个服务，提供 http 出口，来供桌面 cli 或 webhook 等方式来触发。

这种场景，对我的价值是流程编排， 具体逻辑还是在线 pro code 方式写（而不是编排）

[baxtergu]

尝试过用 DataV 的 蓝图编辑器 做过复杂交互的可视化开发，与这个很类似。最终尝试失败后转纯代码开发，当业务需求越来越复杂以后，Low Code 开发成本 >> Pro Code。但是很多需求其实是从简单不断变复杂的，很难在一开始就进行甄别。无论是面向开发人员还是设计人员，最终的可视化逻辑展现都是几乎不可读的，维护和修改成本更高。

这个需要你把需求屡的非常清楚，并且对平台的交互机制有很深的理解，当然如果平台对交互这块没过多考虑的话，那做起来确实麻烦

是这样没错，但是有时候一开始的需求和短期需求是可以 hold 住的（简单业务场景下足够敏捷），当需求复杂度随着时间推移越来越高以后就不行了。（当然我举得这个例子还有一些非技术层面的原因导致的选型问题）

所以我也提到了，其实最关心的是当需求复杂了以后，基于 Low Code 的持续演进带来的成本上升和可维护性下降，让我们不得不转换成 Pro Code 模式，那么这时候转换成本就是一个很关键的点了。（有多少能够重复利用的内容）

---

其实需求复杂后，逻辑编排导出可读的代码继续维护也是一条路。至于代码风格和语言可以自由选择，比如支持导出 js、ts 的，react、vue、angular 框架的，function or class 风格的，css modules or css in js 的。服务端支持导出 node or java 语言的。

有些 Low Code 的思路就是非语言绑定的 DSL，然后再 transform 到需要继续开发的平台中去，不过缺点就是这个过程不可逆，一旦转换成 Pro Code 模式继续迭代就失去了逻辑可视化的能力。对于 “风格” 这点来说，目前最适合流程编排的代码风格之一就是 event driven，这会导致很多原本 Pro Code 中可以同步编写的代码人为转换成了异步的。

---

像 GitHub Actions 类似的场景，感觉如果提供可视化编排能力还是不错的：

• pipeline 主流程通过可视化方式来编排，一般也不会太复杂，几十个节点内，分支也不会太多。
• 部分节点提供在线编辑器来直接编写 pro code 作为处理逻辑。（可以适当要求用户提供输入输出来作为测试）
• 整个 pipeline 可以作为一个服务，提供 http 出口，来供桌面 cli 或 webhook 等方式来触发。

这种场景，对我的价值是流程编排， 具体逻辑还是在线 pro code 方式写（而不是编排）

这个场景目前看来是最“实在”的，Low Code 只做逻辑编排和组合，不做逻辑实现。

[atian25]

如果复杂到一定程度后，得导出为 pro code 了，那这时候其实不需要可逆了，所以不算缺点。

[xudaolong]

与其用流程编排工具输出代码，我倒希望有工具将旧代码导出流程图出来. 😯

[xxholly32]

如果复杂到一定程度后，得导出为 pro code 了，那这时候其实不需要可逆了，所以不算缺点。

很难定义这个复杂的边界，就像我们打咨询电话，只有自己（研发人员）清楚是否应该转人工服务；但对于业务方来说，一旦认定可配就有无尽的“更复杂的开发和配置”

复杂度不会降低，只会转移~

[atian25]

1. 我的观点上面有表达了，我目前还没看清楚在互联网行业的前端聚合层场景下可视化编排的目标用户和价值。
2. 后面的讨论，是基于 其实需求复杂后，逻辑编排导出可读的代码继续维护也是一条路 的假设下。 如何判断『复杂到一定程度』，我觉得就是『编排这段代码的人，觉得看不懂头疼的时候，希望把这段逻辑交接回专业人士时』。

理想的协作模式是：某个活动会经常改些配置或流程小修改，这时候非专业研发同学，基于团队互相补位的考虑，直接被赋能来参与这块的编排（但需要明确的是，这是补位，主要责任人还是研发同学，所以他需要 Review）。然后复杂到一定程度后，自然就应该回归给研发同学来维护，此时编排平台提供的可能是一种从 low code 变为 pro code 的方式，方便后续演进维护。

[JerryXia]

低代码工具有点像是游戏开发里的游戏引擎。

[shwehb]

把一些常用底层功能：存储，链接跳转，http请求，url 分析等抽成一个一个节点，极端的讲，将他们穷举出来，并且支持逻辑编排的模版保存，并且和 nocode UI 打通，实现数据共享配置，是不是就可以实现功能的沉淀。并且支持 节点的插件化，可灵活新增功能节点来实现一些比较复杂且独立的功能。