無代碼工具的自動化概念概述

本文最初發佈於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中的多個動作合併爲一個：

1. 將狀態更改爲計劃中
2. 將計劃季度定爲2020年第一季度
3. 指定給我

這是一個簡單的情況，其中我們選擇的是確切的值，因此可以記錄這個流程並點擊一次即可執行。假設我們創建了一個“計劃”按鈕，點擊這個按鈕後就會執行上述操作。

但情況可能會複雜得多：

1. 創建名爲“搜索模塊中的問題”的新錯誤
2. 分配給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就做得很好。我們可以採用類似的方法嗎？比如說描述初始狀態，描述事件，描述最終狀態等。系統可以基於這些信息自行構建規則嗎？

作者介紹

Michael Dubakov是Fibery創始人，也爲系統、軟件開發和產品主題撰寫文章。

原文鏈接：

https://medium.com/@mdubakov/automations-concepts-overview-for-no-code-tools-8a922ede9bde