低代码-传统开发者的噩梦？

本文主要是介绍低代码-传统开发者的噩梦？，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

使用开源前端和后端框架从头开始开发企业级 Web 应用程序需要很长时间。如今，客户正在寻找快速且具有成本效益的解决方案，并倾向于使用无代码和低代码应用程序开发平台。传统开发人员如何在这个无代码和低代码平台的新世界中顺应潮流？

无代码和低代码平台

这些平台的一个目的是通过利用更广泛的非技术和半技术员工队伍来增加可用的 Web 应用程序开发人员的数量。供应商开发了无代码平台，供非技术人员使用，以构建简单的应用程序，以及低代码平台，供具有基本技术技能的员工使用（例如：SQL、JavaScript）来开发更复杂的企业应用程序。其次，与传统的 Web 应用程序开发方法相比，这些平台可以将 Web 应用程序开发时间减少 50% 以上。

目前，有大量的供应商在无代码和低代码细分市场竞争。无代码平台供应商包括AppSheet（Google），Betty Blocks，QuickBase，Airtable，Bubble和Microsoft PowerApps。低代码平台供应商包括 Microsoft PowerApps、OutSystems、西门子低代码、Salesforce Lightning Platform、Nintex、Appian 和 Pegasystems。

我们不会讨论无代码平台，因为它们迎合了非技术用户开发简单应用程序的需求。作为一名专业的 Web 应用程序开发人员，您不太可能被要求在无代码平台上工作。

另一方面，低代码平台用于开发更复杂的应用程序。对于习惯于使用开源前端和后端框架开发应用程序的专业 Web 开发人员来说，使用这些低代码平台构建 Web 应用程序有几个缺点。这是一篇来自专业 Web 应用程序开发人员的博客文章，讲述了他在这些低代码平台之一上工作的经历。

问题 1：无法控制源代码

低代码平台为开发 Web 应用程序提供了一个视觉隐喻。甚至应用程序的业务逻辑也是通过拖放代码控制语句（如 if/then/else）来实现的。因此，在这些平台上工作的开发人员对源代码几乎没有控制权。无法控制源代码至少会产生两个问题：（a）开发具有复杂业务逻辑的域驱动应用程序具有挑战性，（b）调试问题可能非常困难且令人沮丧。

问题 2：限制职业流动性

在低代码平台上全职工作可能会限制专业 Web 应用程序开发人员的职业流动性。他们将失去目前在开放编程语言和框架方面的技术技能，并在专有的低代码平台中获得技能。假设这个专有的低代码平台没有被雇主广泛采用，目前任何特定的低代码平台都是这种情况。在这种情况下，开发人员的低代码平台技能只能在另一个同样采用相同低代码平台的雇主处使用。这严重限制了开发人员的职业流动性。

有更好的选择吗？是的。为什么不为专业的 Web 应用程序开发人员构建一个低代码平台，既满足雇主对速度的需求，又满足开发人员对控制和职业流动性的需求？我们将此类平台称为“开放”低代码平台。这些平台是如何运作的？继续阅读…

生成样板代码

在开发 Web 应用程序时，有相当多的剪切/粘贴/修改工作。

大多数应用程序使用 N 层体系结构。在此架构中，为了为数据库表（实体）的 CRUD 操作提供 ReST API，我们需要为实体、DAO（数据访问对象）层、服务层和 ReST 控制器层开发代码。同样，为了创建 UI 屏幕以允许最终用户执行 CRUD 操作，我们需要开发 UI 组件和与后端 ReST API 交互的前端服务层。对单个数据库表（实体）完成此工作后，必须对数据库架构的每个表重复类似的工作。

想象一下，必须对 50 个数据库表执行此操作——这是一项繁琐且容易出错的工作。

更好的方法是自动生成此样板代码。为了实现自动化，我们可以开发一个应用程序生成器，该生成器读取数据库模式并生成后端和前端代码，以允许最终用户对数据库表（实体）执行 CRUD 操作。

为常见应用功能提供附加组件

Web 应用程序具有跨应用程序重复的通用功能。此类常见功能的示例包括身份验证和授权、文档管理、事务电子邮件、作业调度程序、用户注册和嵌入式报告。我参与开发的几乎每个 Web 应用程序都需要这些功能。在每种情况下，我的开发团队都重新发明了轮子，并从头开始构建了这些横切关注点，因为我们从未想过构建可以跨 Web 应用程序使用的通用和可定制的通用功能——这是多么浪费精力和时间！

如果此类通用功能的基本代码已经构建并可用，我们可以重用它并根据需要为每个 Web 应用程序自定义它。