低代码开发平台缺失的 5 个关键组件

目前，“低代码”/“无代码”（LC/NC）领域是一个“热门”市场，受到越来越多风险投资的青睐。初创公司正在募集资金，以打造“未来软件开发”的各种愿景。这些平台有一系列的目标用户，从非技术的“公民开发者”到为数更多的技术开发者。它们也有各种各样的用例，从界面/GUI 前端构建到带有逻辑的后端事件处理。低代码能够极大地改善那些寻求快速构建生产工具的开发人员的生活。然而，对于开发人员来说，许多“可视化编程”平台的架构方式限制了其可用性。

本文最初发布于 Jesse Orshan 的个人博客，经原作者授权由 InfoQ 中文站翻译并分享。

声明一下，我是WayScript（一个内部工具的开发中心）的联合创始人。我们已经构建了一个开发工具领域的平台（碰巧有一些部分与低代码重叠，我将在后面介绍）。我是一个后端软件开发人员，具有应用程序开发背景。随着继续学习和构建，我们已经研究了大量低代码产品的特性/决策。

以下是当前平台上缺少的，可能会改变开发人员游戏规则的 5 个组件。

1）一个感觉像在本地主机上的云开发环境

需求：

作为一名软件开发人员，我的工作流程是在本地开发环境中构建软件，然后将其存储在基于云的 Git 存储库中，比如 GitHub。当我编写脚本时，它们通常是在一个虚拟环境中构建，其中包含代码、复杂的文件目录结构和第三方依赖项。问题是，为了将这些本地命令行脚本转换为生产工具，满足基本的生产需求，我还要做更多的工作（准备服务器、部署源代码、配置文件等）。我还必须针对健壮性做很多很多的工作（CI/CD、单元测试等等）。最终，基础设施工作花费的时间与开发核心应用程序一样多，甚至更多。我想要的是一个基于云的开发环境，感觉就像是我的本地主机环境，但可以无缝地将我的脚本目录转换为稳定的生产软件。

当前平台的重心与缺失：

许多 LC/NC 平台的核心是“JSON 解析”工具。这些平台主要是让用户可以拉取 JSON 数据（通常来自第三方 API），并解析特定的键/值对，传递给另一个 API 或接口。

sample_json_data = { 'name'  : 'Jesse Orshan', 'email' : 'jesse[at]wayscript.com', ...}

例如，让用户可以从事件触发器发送sample_json_data.email到另一个 API，而不需要构建底层 API 查询。

我想说的是，JSON 解析服务当然有用，可以用来构建引人注目的自动化/接口。然而，围绕 JSON 解析构建的核心产品架构限制了可以通过低代码增强的应用程序类型。

解决方案：

作为虚拟环境文件系统构建的低代码平台架构，可以读取、写入和删除任意文件结构。当生产就绪时，任何项目都可以通过专用云服务上的核心平台引擎执行。来自事件触发器的 JSON 数据可以作为可导入变量传递到脚本中（例如，当新客户添加到 Salesforce 时运行并传递数据）。此外，这个虚拟文件系统可以支持各种编程语言和现成的依赖关系（Python、Java、C#…）。虚拟环境是基于云的，可以作为跨不同设备和操作系统的统一运行时环境。即使我是在本地桌面上工作，这个环境也运行在云中，但感觉上与我的本地机器没有区别。最后，这个虚拟环境可以与 GitHub、S3、Dropbox 等第三方文件结构进行交互。该系统是无缝式的，因为云服务器上用于生产执行的配置文件是由平台自动构建的（如果需要更多的定制，则可以编辑）。

2）优先考虑编码的易用性而不是拖放

需求：

一个面向任何代码库（服务器、任务等）的、便利的事件触发和软件托管/运行平台。

当前平台的重心与缺失：

大多数人在想到低代码时，他们想到的是可视化编程（也就是终端用户开发）。虽然可视化编程只是一个典型的实例，但实际上，软件开发中的所有东西都是“低代码”——通过高级接口对低级代码进行抽象。例如，Python 编程语言可以被解释为低级 C 语言代码的抽象。其次，像 Twilio 这样广受欢迎的 API 改进了从头构建文本消息传递接口的方法。换句话说，API 和可视化编程接口一样都是低代码产品。这里的重点是，低代码和可视化编程之间是有区别的。

这种区别产生了两个问题。首先，可视化编程是生产级脚本和工具的恰当范式吗？其次，这些平台最有价值的功能是什么？

对于第一个问题，答案是，可视化编程可以为软件开发带来帮助，但也可能会成为一种阻碍，因为它可能会为了自身的发展而把某些功能强加给用户。举个例子，一个有用的可视化界面，可能是设置一个 cron 作业来执行脚本，或是与一个简单的 API 交互。通常，从可视化编程中受益的用例是那些需要大量的专用代码来提供简单的通用功能的软件组件。但是，如果强制整个平台都使用可视化编程，那它最终就会成为一种障碍。通常，要表达你想要做的事情，代码是最简单、最快速的方式。例如，用可视化编程构建if/else语句这样的布尔逻辑，很快就会变得难以设置和管理。作为一名开发人员，我宁愿用 Python 编写逻辑。

那么可视化编程平台最有价值的特性是什么呢？首先，内置的基于事件的触发机制有很大的好处（例如，每当一个新客户添加到数据库或 CRM 时运行）。这很有用，因为设置这种类型的触发系统需要另一个编码项目（托管一台服务器处理传入的 webhook），并且会分散我的注意力，影响我解决我正在设法解决的核心问题。其次，这些平台能够无缝地在云中运行构建好的自动化流程，而不需要任何 DevOps 过程，这是有好处的。

解决方案：

一个从第三方 API（至少是一个通用的 HTTP 端点）集成事件触发的虚拟环境平台，可以在应用程序执行时将请求响应数据推送到脚本中。其次，内置处理 OAuth/认证、简单参数输入和适当查询的 API 可以节省时间。这些 API 也可以受益于可视化界面（发送自定义电子邮件、Slack 消息等）。

3）文件依赖关系管理

需求：

服务应该“聪明”地理解依赖关系，并将其视为需要解决的第一类问题。例如，如果一个内部工具依赖于一个特定目录位置的文件、一个特定的 db schema 或另一个常量，那么平台至少应该能够识别出破坏性的更改，并立即向涉众解释更改的内容。最好的体验是最小化用户构建单元测试所要完成的工作。

当前平台的重心与缺失：

当与构建内部脚本和工作流自动化的团队一起工作时，我们经常发现，共享文件在生产稳定性方面是一个潜在的压力点/弱点。例如，我们与一家在 Google Sheet 上运行工作流自动化的公司合作，该表可以由员工同时编辑。如果一个工作表、列或特定的单元格被意外地编辑了，自动程序会在没有任何提示的情况下中断。这时，追踪根本原因就会遇到调试困难、非常耗时的问题，而且无法防止将来出现同样的问题。还有一种情况，一家公司有一些内部工具，它们希望数据库模式是某种格式的，但是当数据库升级时，这些工具都崩溃了。现实情况是，文件依赖关系和真实世界的数据都很混乱，许多平台希望用户管理这种混乱。

解决方案：

平台自动为每个程序生成的配置文件应该包括程序中使用的所有文件和文件夹的映射。对这些文件的任何引用都应该存储在元数据中。换句话说，应用程序“理解”文件依赖关系和依赖关系的性质（目录位置、内部数据结构、类型等）。在这样的架构下，我们可以设想有一个低代码映射，它显示了正在运行的脚本和工具系统中的所有文件的相互依赖关系。

4）版本控制 &存储库集成

需求：

平台模式要允许用户在一个云虚拟环境中无缝地运行代码、脚本和服务器，而不需要开发运维或设置（感觉就像你的本地环境）。与保存在第三方服务数据库中的专有程序相比，就一个文件结构进行版本控制和协作要非常简单。换句话说，用户拥有源代码而不是服务。

当前平台的重心与缺失：

许多终端用户 LC/NC 编程平台的架构将程序内容存在公司数据库中（Zapier 存储你的“zaps”等）。这种模式与大多数开发人员在构建工具时使用的 git/repository 模式相反。像 GitHub 这样的 git 模式其好处是提供了版本控制、可共享性、可移植性和协作性（例如开源 repo）。对于构建工具，一种允许开发人员将所有元素视为目录中的文件来存储并就程序开发进行协作的范式至关重要。这又回到了一个观点，即低代码程序的核心应该作为系统中一个可编辑的文件，而平台的目的是帮助用户进行配置（无论是通过可视化编程还是出色的文档）。这种模式解锁了更复杂的工具，并且可以利用许多软件开发人员已经使用的工具，如 GitHub 的源代码控制。此外，这样的架构还解锁了一种更加模块化的开发体验，让开发人员可以操作更基础的部分（换句话说，如果需要的话，用户可以编辑/理解最低级的代码）。

在我看来，GitBook平台在构建文档方面做得很好。主要是，GitBook 提供的可视化界面使它非常容易构建动态文档，底层内容以 markdown 文件存储库的形式存储在每个用户的 GitHub 账户中（查看文档和底层文件结构）。借助 GitHub，GitBook 能够利用这个平台进行冲突管理，并为开发者提供更好的低级特性。

解决方案：

一个可以帮助/自动在源代码中构建配置文件，以便在云服务（脚本、服务器/端点等）中运行任意代码的 LC 平台。与脚本相关的所有文件都归用户所有并由用户存储，而不是服务数据库。所有的服务存储都是引用这些文件的存储位置（GitHub、S3、Dropbox 等）。

5）供应商灵活性

需求：

供应商强制锁定给开发人员造成了真正的障碍。如果一家公司倒闭或涨价会发生什么？如果我突然需要服务无法提供的特性或更多资源，该怎么办？如果我被供应商锁定，这些就成了问题。

当前平台的重心与缺失：

在构建软件工具时，其中许多会随着时间的推移而成为关键任务型工具。作为一名开发人员，从零开始构建工具的一个巨大的价值主张是我有完全的自主权。我可以决定使用哪个框架，在哪里托管等等。

如今，大多数可视化编程平台生来就会将用户锁定在他们的系统中，并将这种“粘性”视为一种商业利益。例如，在许多情况下，使用 AirTable 非常方便，但在构建工具时也会带来一些不便。主要是，即使需要/想要，我也无法访问底层关系型数据库。

解决方案：

一个将其提供的每个服务组件（例如事件触发、托管、凭据等）都视为存储库中的一个文件的平台。在这种模式下，我可以按自己希望的方式编写所有的代码，并且随时可以用另一个服务替换配置文件（例如，用 Heroku ProcFile 替换 AWS 配置文件）。是的，这项工作有时很乏味，但我需要有选择。其次，该架构可以推动供应商提供一流的组件服务，否则这些组件将被替换为更好的服务。

小结

低代码能够极大地改善那些希望快速构建生产工具的开发人员的生活。然而，低代码“可视化编程”平台的架构往往限制了开发人员的使用。能够解决这些问题的服务将符合所有开发人员的主要价值主张。

你怎么看？作为开发者，你觉得这些平台还存在其他问题吗？

英文原文链接：5 Things Low-Code Is Missing