为什么开发人员需要更多地了解低代码工具

低代码简史

“低代码”一词源于低代码平台的日益普及和市场吸引力,这些平台以快速应用程序开发 (RAD)、移动应用程序开发和云应用程序开发(PaaSaPaaS)解决方案的形式出现。这个词是大约六年前由 Forrester 分析师 John Rymer 和 Clay Richardson引入的,他们希望对 Mendix、OutSystems、Salesforce (force.com) 等公司的产品进行分类。

今天低代码的定义有很大的不同。它最初是为在软件应用程序开发方面具有最少专业知识的用户描述“有意见的”或声明性平台的一种方式。随着时间的推移,低代码用户的范围扩大到包括从专业开发人员到完全没有开发专业知识的所有人。然而,开发人员角色与低代码有着复杂的关系。

为什么开发人员需要更多地了解低代码工具

低代码对开发人员的意义

对于一些开发人员来说,低代码是“开发人员不友好”的同义词。在创建声明式平台的过程中,许多供应商剥夺了编写自己的代码所带来的透明度。这让开发人员很难解决他们不是从头开始编写的应用程序中的问题。这使得更新这些应用程序变得困难,尤其是当它们与遗留系统或复杂环境相关联时。

将软件开发工具归类为“抽象工具”或“复杂性探索工具”。抽象工具简化了许多重复性任务,这可能是一件好事。然而,大多数现代生态系统都无法仔细规划,并且由各种不断发展的编程语言和运行时组成。 

要创建对开发人员友好的体验,必须为开发人员提供抽象和复杂性探索能力的健康组合。在某些情况下,这些功能可以共存于同一个工具中。 

分解自动化中的低代码

低代码增长最快的自动化用例之一是机器人流程自动化 (RPA)。在某些情况下,轻量级 RPA 机器人可用于自动化一个简单的过程(例如,代表新用户运行信用检查或基于特定阈值分数接受或拒绝请求)。然而,随着事件驱动的流程变得越来越复杂,RPA 部署可能会成为不必要的瓶颈,甚至会因遗留应用程序和系统的重量而倾倒。

这就是开发人员解开低代码纱线球的工作开始的地方。

由于流程本质上由人和技术组成,因此对于开发人员和业务用户来说,混合抽象和复杂性探索功能非常重要。例如,业务利益相关者需要从一开始就参与流程设计,以确保他们的要求反映在最终的自动化产品中。标准如业务流程模型和符号BPMN)是指通过分解复杂的过程转化为易于理解的流程图图来这些利益相关者参与。此步骤将被视为“低”或“无代码”。

从那里开始,开发人员工具需要混合使用 BPMN 等开发人员快捷方式来定义编排流程,并能够深入挖掘以在需要时进行自定义代码级更改。对开发人员友好的方法应该从开放灵活的架构开始。自动化项目很少是简单的。当最有效地完成时,它们会逐渐推出。它们通常由现代的、基于微服务的应用程序(无论是自制的还是购买的)拼凑而成,这些应用程序可以很好地与 API 和不适用的遗留应用程序配合使用。

将软件集成到现有技术堆栈和开发环境中的灵活性是确保自动化项目成功的关键。删除和替换堆栈中的每一项遗留技术并从头开始重写基于微服务的应用程序似乎是个好主意。但是,对于较大的组织,渐进式方法的破坏性要小得多。编排技术可以帮助处理旧的,同时集成新的。

结论

开发人员在设置自动化部署时仍然需要捷径,但前提是他们可以自由地钻取并探索底层系统和代码的复杂性。

如果出现问题或需要定制,复杂性探索工具实际上可以提高开发人员的工作效率,而不是让他们在本应简单的黑盒平台中导航。在设计阶段,开发人员应该能够帮助他们的利益相关者以最小的麻烦来可视化和更改流程的基本架构。

低代码与专业代码的答案并不总是一个非此即彼的命题。相反,工具应该旨在帮助开发人员在您的生态系统的“热带雨林”中导航——即使这意味着拉开低代码的帷幕,以便他们可以在幕后进行自定义更改。