低代码缺失的五件事
当前，“低代码” /“无代码”（LC / NC）空间是一个“热门”市场，越来越多的高端风险投资投入。初创企业正在获得资金以树立“软件开发的未来”的各种愿景。这些平台的目标用户范围广泛，从非技术性的“公民开发人员”到更多技术性开发人员。它们还具有不同的用例，范围从接口/ GUI前端构建到使用逻辑进行后端事件处理。
Low-Code可以从根本上改善希望快速构建生产工具的开发人员的生活。但是，许多“视觉编程”平台的构建方式都限制了开发人员的可用性。
免责声明，我是@ WayScript的共同创始人-内部工具的开发中心。我们已经在开发人员工具空间中构建了一个平台（碰巧会有一些低代码重叠，稍后再讲）。我是一名后端软件开发人员，具有应用程序开发背景。随着我们不断学习和构建，我们研究了投放市场的低代码产品的众多功能/决定。
因此，这是当前平台上缺少的5个组件，它们将对开发人员产生巨大的变化。
作为软件开发人员，我的工作流程是在本地开发环境中构建软件，该环境随后存储在基于云的git存储库（例如GitHub）中。在编写脚本时，它们通常是在包含代码，复杂的文件目录结构和第三方依赖关系的虚拟环境中构建的。麻烦在于，为了将这些本地命令行脚本转换为生产工具，我需要为基本生产做更多的工作（配置服务器，部署源代码，配置文件等）。我还必须做很多工作才能提高鲁棒性（CI / CD，单元测试等）。与基础应用程序相比，许多此类基础结构工作最终需要花费更多或更多的时间。我想要的是一个基于云的开发环境，感觉就像我的本地主机环境，但是将我的脚本目录无缝转换为稳定的生产软件。
许多LC / NC平台的核心都是“ JSON解析”实用程序。主要是，该平台使用户能够提取JSON数据（通常从第三方api），并解析特定的键/值对以传递给另一个API或接口。
例如，用户有权将sample_json_data.email从事件触发器传递到另一个API，而无需构建基础API查询。
我想提一下，JSON解析服务当然很有用，可用于构建引人注目的自动化/接口。但是，围绕JSON解析构建的核心产品架构限制了可以通过低代码增强的应用程序类型。
低代码平台体系结构，构建为虚拟环境文件系统，可以读取，写入和删除任意文件结构。准备投入生产后，可以通过专用云服务上的核心平台引擎来执行任何项目。可以将来自事件触发器的JSON数据作为可导入变量传递到脚本中（例如，在将新客户添加到Salesforce并传递数据时运行）。而且，该虚拟文件系统可以支持各种编程语言和开箱即用的依赖项（python，java，c＃等）。虚拟环境是基于云的，并且可以作为跨各种设备和操作系统的统一运行时环境。即使在我的本地桌面上工作时，该环境也可以在云中运行，但是与我的本地计算机没有区别。最后，该虚拟环境可以与第三方文件结构（例如GitHub，S3，Dropbox等）进行交互。该系统是无缝的，因为该平台可自动构建用于在云服务器上执行生产的配置文件（如果需要更多自定义，则可以编辑需要）。
一个平台，可以轻松地为任何代码存储库（服务器，任务等）进行事件触发和软件托管/运行。
当大多数人想到低代码时，他们就会想到可视化编程（也就是最终用户开发）。尽管可视化编程是一个示例，但实际上，软件开发中的几乎所有内容都是“低代码”，即通过较高级别的界面对较低级别的代码的抽象。例如，Python编程语言可以解释为C编程语言的低代码抽象。其次，诸如Twilio之类的流行API与从头开始构建文本消息接口相比，是一个低代码的改进。换句话说，API和可视编程接口一样，都是低代码产品。这里的重点是，低代码和可视编程之间应该有所区别。
这种区别引发了两个问题。首先，可视化编程是生产级脚本和工具的正确范例吗？其次，这些平台最有价值的功能是什么？
对于第一个问题，答案是视觉编程可以在软件开发中提供有用的帮助，但是当它被迫为自己着想时也可以成为障碍。有用的可视界面的一个示例可能是设置cron作业以执行脚本或与简单的API交互。通常，受益于视觉编程的用例是软件的组件，这些组件需要大量专门的代码才能提供简单而通用的功能。但是，通过强制整个平台使用可视化编程，您最终会陷入阻碍的境地。通常，代码是表达您想要做的事情的最简单，最快的方法。例如，使用可视化程序构建布尔逻辑（例如if / else语句）很快就变得难以设置和管理。作为开发人员，我宁愿只用python编写逻辑。
那么可视化编程平台最有价值的功能是什么？首先，基于事件的内置触发机制有很大的好处（例如，每当有新客户添加到我的数据库或CRM时就运行）。这很有用，因为设置这种类型的触发系统需要另一个编码项目（为传入的Webhooks托管服务器），并使我无法解决要解决的核心问题。其次，这些平台无需任何开发流程即可在云中无缝运行已构建的自动化功能的能力是有益的。
一个虚拟环境平台，具有从第三方API（至少是可通用化的HTTP端点）触发的集成事件触发，可以在应用程序执行时将请求响应数据推送到脚本中。其次，在处理oauth /凭证，易于输入参数和正确查询的API中进行烘焙可以节省时间。这些API还受益于可视界面（发送自定义电子邮件，松弛消息等）。
该服务应该“聪明”地了解依赖关系，并将其视为要解决的头等问题。例如，如果内部工具依赖于特定目录位置，特定数据库模式或另一个常量中的文件，则平台至少应识别出重大更改，并立即向涉众报告警告更改内容。最好的体验将使用户以最少的工作量轻松构建单元测试。
与团队一起构建内部脚本和工作流自动化时，我们经常发现共享文件是潜在的压力点/生产稳定性的弱点。例如，我们与一家在Google表格上运行工作流程自动化的公司合作，该工作表同时由员工进行编辑。如果不小心编辑了工作表，列或特定单元格，则自动化将中断而没有任何指示（至少不是立即显示）。当调试困难，耗时且在将来无法避免此问题时，在此处查找根本原因。在另一种情况下，一家公司有一些内部工具，它们期望数据库架构采用某种格式，并且这些工具在升级数据库时都崩溃了。现实情况是文件依赖性和真实世界的数据都是混乱的，许多平台都希望用户能够管理这种混乱。
该平台为每个程序自动生成的配置文件应包括该程序中使用的所有文件和文件夹的映射。对这些文件的任何引用都应存储在元数据中。换句话说，应用程序“了解”文件依赖关系和依赖关系的性质（目录位置，内部数据结构，类型等）。通过这种体系结构，可以预见一个低代码映射，该映射显示正在运行的脚本和工具系统中所有文件的相互依赖性。
一种平台范例，使用户可以在云虚拟环境中无缝运行代码，脚本和服务器，而无需进行开发操作或设置（感觉就像您的本地环境）。与存储在第三方服务数据库中的专有程序相比，版本控制和协作要容易得多地应用于文件体系结构。换句话说，用户拥有源代码而不是服务。
许多最终用户编程LC / NC平台都是经过架构设计的，因此程序内容位于公司数据库中（Zapier存储您的“ Zap”等）。此范例与大多数开发人员在构建工具时使用的git /存储库范例相反。像GitHub这样的git范例的好处是版本控制，可共享性，可移植性和协作（以开放源代码存储库为例）。对于构建工具而言，通过将所有元素都视为目录中的文件，使开发人员能够在程序上进行存储和协作的范例至关重要。这回到了一个想法，即低代码程序的核心应该在系统中以平台上的目的是帮助用户进行配置（无论是通过可视化编程还是编写出色的文档）来作为可编辑文件工作。这种范例释放了开发更复杂工具的能力，并且可以利用软件开发人员已经使用的许多工具（例如GitHub）进行源代码控制。另外一个好处是，这种相同的体系结构可带来更多模块化的开发体验，在该体验中，可以操纵更多基本部分（换句话说，用户可以根据需要编辑/理解最低级别的代码）。
我认为，平台GitBook在构建文档方面做得很好。主要是，GitBook提供的可视界面使构建动态文档变得非常容易，基础内容作为markdown文件的存储库存储在每个用户的GitHub帐户中（请参阅此处的文档和基础文件结构）。通过利用GitHub，GitBook能够利用该平台进行冲突管理，并为开发人员提供更好的底层功能。
一个可在源代码中辅助/自动构造配置文件的LC平台，以在云服务（脚本，服务器/端点等）上运行任意代码。与脚本相关的所有文件均由用户而非服务数据库拥有和存储。所有服务存储都引用了这些文件的存储位置（GitHub，S3，Dropbox等）。
强制供应商锁定对开发人员造成了真正的障碍。如果公司停业或提高价格会怎样？如果我突然需要该服务无法提供的功能或更多资源，该怎么办？在这些情况下，如果我被锁定，将是一个问题。
在构建软件工具时，随着时间的流逝，许多工具往往变得至关重要。作为开发人员，从头开始构建工具的巨大价值主张是我拥有完全的自主权。我可以决定使用哪些框架，在何处托管等。
如今，大多数可视化编程平台都固有地以其范式将用户锁定在他们的系统中，并将这种“粘性”视为商业利益。例如，在许多情况下，使用AirTable极为方便，但是在构建工具时，也会产生一些不安作为选择。主要地，如果我需要/想要的话，我没有访问基础关系数据库的能力。
一个平台，将其提供的服务的每个组件（例如事件触发，托管，凭据等）都视为存储库中的文件。通过这种范例，我可以编写自己的所有代码，并且可以始终用其他服务替换配置文件（例如，将AWS config文件的Heroku ProcFile交换为示例）。是的，有时这项工作很乏味，但我需要选择。其次，此体系结构调整了对服务的激励，以为其组件提供一流的服务，否则这些组件将被交换为更好的服务。
低代码可以有效改善希望快速构建生产工具的开发人员的生活。但是，利用低代码的“可视化编程”平台通常以限制开发人员使用的方式进行设计。解决这些问题的服务将是所有开发人员的主要价值支持。
你有什么感想？作为开发人员，这些平台是否还有其他主要问题？
在WayScript上，我们正在为希望快速构建内部工具的开发人员构建一个平台。 在以后的文章中，我将写一篇关于如何构建我们的平台以解决本文提出的问题的后续文章。
