无代码工具的自动化概念概述-InfoQ



 写点什么

本文最初发布于 Medium 博客，经原作者 Michael Dubakov 授权由 InfoQ 中文站翻译并分享。

几乎所有正规的无代码工具都应该具备某种程度的自动化能力。自动化是高效系统的基础，它可以帮助人们提高生产力。系统的第一阶段肯定是数据收集，而第二阶段就是自动化。

我们正在考虑在 Fibery（https://fibery.io/）中实现自动化，因为 Fibery 中的数据收集问题似乎已接近完善。但是，创建自动化操作是非常困难的，因为它非常接近编程的形态。在本文中，我简要回顾了在系统中添加自动化层的所有可行方法。如有补充意见请随意发表评论。

问题

你必须向计算机说明你需要什么样的自动化流程，并且要阐述得足够精确，以免误导计算机。任何模糊不清的部分都会带来错误和不良后果的代价。

##当前解决方案

基于编程语言

低级代码（脚本语言）

最低层的方法就是代码。脚本语言已在 HyperCards、FileMaker 等许多软件工具中广泛使用。它提供了巨大的灵活性，但也存在很高的入门门槛，只有程序员才能完全掌握它。

使用 HyperCard 脚本语言来编程行为

图形语言

我们可以使用图形块+文本来表示代码。例如 Scratch（https://scratch.mit.edu/）就使用了这种方法，小朋友们很容易就能掌握它。

一般来说，这种系统的能力可以与低代码解决方案相提并论，因为你依然可以使用所有编程语言构造进行操作。这里的好处是更清晰地确定范围并预防不良的组合。例如，你不能将某些块插入另一个块中，因为它们的形状是不同的。这样可以避免某些错误。

缺点是对于大型程序来说这种方法很难掌握。但只要自动化的规则足够简单，这种方法使用起来就完全没有障碍。

“家庭自动化”

DSL

我们可以创建一种仅用于自动化目的的特殊语言。在这种情况下，知识工作者就能更容易掌握自动化操作，因为你可能使用熟悉的术语并限制语言的灵活性。例如，一般人很难理解迭代器和递归，更不用说要调试它们了，因此 DSL 可能会将这类构造包装成不太复杂的东西。

When Task.State.Name is “Coded” Then GitLab["Profile"].Create.PullRequest(Task.Id + Task.Name)

复制代码

这种方法可能很有前途，但对于大多数人而言，控制台界面是很难用的。看来这应该是其他解决方案的后备选项。

自然语言处理（NLP）

像 Siri 这样的工具展现出了一些可能性。一般来说，有些人会使用它来执行诸如设置会议时间或发送电子邮件之类的操作。但这并不算在自动化的范畴之内。NLP 可以用来描述自动化的需求，但这即使在概念上也是很难做到的，更不要说还得考虑种种技术难题。我们必须将人类文本转换为正式的较低层结构（例如 DSL），这很难做到。不过 NLQ（https://community.microstrategy.com/s/article/Natural-Language-Query-in-A-Nutshell-MicroStrategy-11-0?language=en_US）中有一些尝试看起来很有趣。

Forms

Forms 是最流行的自动化规则设计方法之一。像 IFTT 和 Zapier 之类的众多系统都遵循这种方法，并且都非常成功。

当……时做……

人们很熟悉点击界面，因此可以很自然地将这种方法用在所有事情上。

问题在于自动化规则是一种算法，而不是静态结构。而且很难使用静态图像和静态 UI 来可视化诸如算法之类的动态事物。你必须能通过 UI 的一些视觉提示来在头脑中重现整个流程。

Zapier 自动化流程

Fibery.io 原型

举个例子

宏录制

我们可以向系统“展示”我们想要做什么，并“记录”一个手动流程以将其转换为自动化流程。例如，Photoshop 的宏就可以记录并执行用户在很多图像上执行的操作。

对于单个系统，这似乎是一种可行的方法，但是对于多个系统，这几乎是没有可行性的。

例如，我们可以将 Fibery 中的多个动作合并为一个：

将状态更改为计划中
将计划季度定为 2020 年第一季度
指定给我

这是一个简单的情况，其中我们选择的是确切的值，因此可以记录这个流程并点击一次即可执行。假设我们创建了一个“计划”按钮，点击这个按钮后就会执行上述操作。

但情况可能会复杂得多：

创建名为“搜索模块中的问题”的新错误
分配给 Vadim

总体来说，我们希望将所有与搜索相关的错误指定给 Vadim，但系统不会理解这种阐述。如果我们要创建这个宏，那么在宏里阐明我们所需的内容可能要比从头开始制定所有规则来得更容易一些。想象一下，我们可以编辑宏并为实体的创建设置条件（过滤器？），例如 Name.Contains(“Search”)。

块模式

你可以使用伪代码或块模式来组装自动化规则。这里的优点是它能以某种方式可视化流。你可以想象实体通过一些条件和动作，从最高状态流向最低状态。它仍然是一种抽象表示，几乎没有在基本文本之上添加任何有用的东西。实际上，你可以想象每一行文本都是下一个步骤，并且具有非常相似的表示形式，但有一处不同——那就是条件逻辑。在块模式中查看逻辑分支要容易得多：

此外，在这里我们具有可以直接操作的 DnD 界面，它更接近所见即所得的原理。基本上，你要为算法的每个步骤命名，因此可以更好地了解此处正在发生的事情。但是，每个步骤的细节都有所隐藏，因此对于高级用户而言，这可能不是创建自动化操作的最快方法。

混合方法

块模式+Forms

你可以使用块来创建高级流程，并使用 Form UI 指定块的细节。

Tray.io 混合方法

块模式+代码

你可以使用块来创建整体流程，但是每个块内部都有 DSL 或代码。这样你就将算法/流的创建分解成了许多可管理的部分，而且看上去可能根本就不像是编程。Fibery 中的公式就是这种方法的一个例子，并且这种水平的复杂性可能会足够低，让很多人都能创建自动化流程。

笔记，想法和观察

自动化创建是一项繁重的认知任务。这需要一个人付出巨大努力，并且需要某种“面向程序的思想”。你必须仔细考虑具体的流程，这往往是很难的。甚至最简单的算法也很难掌握并内部化为一种正规的形式（https://www.youtube.com/watch?v=Ct-lOOUqmyY）。
验证和调试自动化规则非常困难。你应该能了解步骤为何失败以及失败的原因。这编程是非常接近的。
连接外部工具非常困难。你必须跨越身份验证障碍，并以某种方式学会工具术语以了解该怎么做。如果不同的工具用不同的方式命名相同的事物，则每次创建规则时都需要克服这种不匹配的麻烦。
似乎带有一些实时反馈的所见即所得方法（请查看 BretVictor 的想法「http://worrydream.com/#!2/LadderOfAbstraction」），是比较适合一般人使用的。但流程可视化仍然很难。我们应该尝试通过视觉队列、当前状态可视化等方式来帮助大众。我们应该让人类的思想有更大的施展空间，并帮助他们突破规则创建的障碍。例如，用户可以提供一些示例数据，并且在每一步操作上我们都可以展示这些数据变成什么样了。
声明式方法很有趣。我们能否描述我们想要用规则实现的目标，而不是具体描述规则的细节呢？SQL 就做得很好。我们可以采用类似的方法吗？比如说描述初始状态，描述事件，描述最终状态等。系统可以基于这些信息自行构建规则吗？