低代码平台是新的类似 Visual Basic 的工具吗?

低代码平台对于寻求内部产品开发方法的公司来说是一个福音,该方法为构建其系统提供灵活性和敏捷性。它们是一种利用技术娴熟的资源而无需成熟的软件工程师的方法。

术语低代码可能是新概念,但为构建技术复杂的系统提供更简单、抽象的工具的概念不是。寻找低代码供应商的公司可以从该领域过去的经验中吸取教训。

是产品还是平台?是买还是自建?

许多公司认为低代码是一种介于于“购买与构建”中间的方式。其实不是,为了解释,让我们解释下产品和平台之间的区别。

区别在于,当公司购买和安装产品时,供应商将继续维护和升级提供一整套服务。而对于平台来说,供应商只会将平台维护和升级到核心平台功能的级别。供应商提供的任何加速器、模板、示例站点等均按原样提供。

平台供应商稍后为模板所做的任何更改都不会根据模板的先前版本自动应用于买方的生产环境;使用行业垂直模板通过低代码平台投入生产可能比配置成熟的产品更快。不同之处在于长期支持和所有权。

Visual Basic、数据库脚本和低代码:表示层中的业务逻辑

visual basic

保险公司、银行和其他金融服务公司早在低代码出现之前,就在利用技术平台在加快开发速度。最明显的例子是 Visual Basic,它于 1991 年首次为 Microsoft Windows 发布。Visual Basic 是用于创建桌面 Windows 应用程序的可视化工具,毫无疑问它是低代码。

公司采用 Visual Basic 来构建内部应用程序。尽管如此,Visual Basic 的问题在于,所有使它易于使用的东西,都会使它成为长期维护的噩梦。保险公司的每条业务线都构建了可以快速设置但难以维护的应用程序。

最大的问题是 Visual Basic 鼓励用户将业务逻辑直接构建到用户界面中。但是,最佳实践是将业务逻辑保留在单独的层中,从而允许跨许多不同类型的接口重用核心业务规则。当保险公司想要构建 Web 门户、移动应用程序和其他形式的交互时,直接构建到 VB 应用程序中的业务逻辑不仅需要重写,而且还需要逆向工程。

Visual Basic 并不是唯一的罪魁祸首。许多公司将 Microsoft Access 用于简单的数据库应用程序。在复杂性的另一端,公司使用 Oracle 的 PL/SQL 语言将业务逻辑直接编程到数据库中。将业务逻辑与表示或数据库相结合会产生长期的支持和维护问题,以及系统核心深处难以记录的规则遗留问题。

低代码同样需要避免影子 IT

影子IT

这并不是说低代码是不好的,或者它必然会创建一个影子 IT 环境。尽管如此,关键的公司业务逻辑仍有可能在显示层中丢失,就像在 Visual Basic 的全盛时期一样。

任何公司的低代码都需要涉及 IT 并遵循标准软件开发生命周期最佳实践。一个强大的低代码平台可以支持构建用户界面、流程管理、工作流和业务逻辑。然而,这一切都需要通过适当的抽象和 N 层架构方法来完成。

使用低代码平台的公司的目标应该是确保他们现在构建的应用程序不仅可以快速上线,而且易于维护和更换。

推荐阅读:企业软件解决方案的 4 种类型