小程序转换纯数字数字

最近，许多低码/无码解决方案在企业中得到了发展，使非技术人员可以选择创建简单的应用程序。 分析人士预测，低码行业将以每年20％以上的速度增长。 但是什么是低码，为什么它如此流行，它又有什么问题呢？

低码是我们在过去几十年间偶尔看到的东西–拖放式UI设计器，使您可以创建简单的应用程序而无需编码技能。 产品已经成熟，并且几乎都提供了类似的功能-在拖放式实体关系图中设计实体关系的能力，通过所见即所得设计UI的能力，通过类似于BPMN的符号设计简单流程，通过BP调用外部服务的能力导入Web服务定义，以便从预烘焙的实体定义中进行选择，以及在外部数据库和电子表格中获取和存储数据。

该领域中有许多工具-MS PowerApps，OutSystems，Appian，Mendix，Google最近收购的AppSheets，Ninox，WaveMaker等。 而且它们的方法和功能集可能略有不同，但总的来说，是要能够轻松创建应用程序（基于Web，基于移动设备，混合），以解决这些用户遇到的一些即时难题。一个成熟的IT项目及其相关的开发成本实在是过大了。

这听起来很棒–您不必依靠非IT公司中过于忙碌且React不频繁的IT部门，您只需自己构建一些东西即可优化您的紧迫问题并数字化您的书面流程。 它可以做到。 老实说，我喜欢这种工具的想法，因为很大一部分集中式系统和多年的开发项目无法很好地处理数字转换的大部分内容。 在这样的环境中，需要越来越多的敏捷性，而对于数字转换的需求却越来越大，而昂贵的开发人员却只能提供有限的可用性。 我们必须承认，专业开发人员不可能无处不在，无法解决信息技术可以解决的所有问题。 这样的工具使数字化转型民主化，允许非技术人员创建软件。

或至少这是理论。 实际上，这在许多方面都具有挑战性：

• 需要一些技术知识 -能够绘制实体关系图很酷，但是首先您需要知道什么是数据模型。 能够导入Web服务并能够调用它是很好的，但是您必须知道Web服务是什么。 集成用户目录意味着您知道什么是LDAP / AD。 我不确定非技术人员能否真正利用这些功能。 即使打开一个新对话框，某些工具仍然需要简单的代码，并且您必须从某个地方复制粘贴该代码。
• 与本地系统集成 –构建有用的东西几乎总是需要与现有系统集成。 可以假设一切都在“云”中，这很好，但是从第三方SaaS的角度来看，即使云也可以视为内部部署。 我见过的许多工具都通过提供IP，用户名和密码来与数据库集成-几乎从来没有，这是一个坏主意。 连接到组织机构基础结构中某物的能力（即使该基础结构位于Azure上并且您正在使用MS PowerApps）也意味着权限，网络规则配置，帐户，批准。 而且您必须知道要求什么才能得到它。
• 供应商锁定 –大多数低代码工具使用专有格式进行元描述（例如，有些甚至将其元数据的二进制表示形式存储在本地sqlite数据库中）。 一些提供程序允许您通过安装他们的服务器端应用程序在自己的云上运行该应用程序，但是一些纯粹是SaaS。 使用一种工具构建应用程序后，就无法真正切换到另一种工具。 WaveMaker和Skyve是很好的例外，它们会生成实际的Java代码，您可以随时下载它们。 锁定不好吗？ 好吧，是的–如果碰巧您需要尚不可用的功能或尚不存在的集成功能，那么您就陷入了困境。
• 影子IT –假定组织中的所有IT都由IT部门进行管理和观察。 在监视，安全性，合规性，数据保护，生命周期管理，技术支持等方面。使用低代码，这些应用程序可以存在，而IT部门甚至不知道它们，并且带来很多风险（我将在下面讨论）
• 可持续性 –如果一家低代码公司倒闭，或者被决定淘汰某个产品或一系列功能的人收购，该怎么办？ 当创建低代码应用程序的员工离开并且没有人知道如何使用所选工具进行“编程”以支持该应用程序时，会发生什么？ 低代码应用程序本身成为旧版时会发生什么？ 由于供应商锁定并且缺乏任何标准化，因此在可持续性方面承担着很大的风险。 当然，您可以通过某种方式解决当前的问题，但是您可能会在此基础上创建更多的问题。
• 安全性 –一方面，使用PaaS / SaaS可能被视为内置安全性。 另一方面，非技术人员无法评估给定平台的安全性。 安全性不能完全“内置” –您必须确保需要身份验证，在列入白名单的办公地点之外看不见应用程序，未经授权的人员不能导出数据，并且必须保护自己XSS，CSRF，SQLi等。 即使平台提供了这些选项，非技术人员也不知道他们必须首先照顾它们。
• 合规性 –许多行业受到监管，并且有横向法规，例如数据保护法规（GDPR，CCPA）。 数据泄露经常发生是因为数据是从其原始的受良好保护的存储中取出的，并保存在数据保护人员不知道的地方（例如低代码应用程序）。 加密，匿名化，数据最小化，保留期–大多数低码解决方案都不支持这些功能，不熟悉这些细节的员工不太可能花更多的精力来兼容该应用程序。
• 无法控制的错误–当您的软件中存在错误时，可以对其进行修复。 如果在库中，则可以对其进行修补。 如果在第三方平台的一组工具中，您将无能为力。 在测试几种低代码解决方案的过程中，我偶然发现了许多错误和不一致之处。

其中一些问题也存在于常规项目中。 开发人员可能不知道如何使应用程序符合GDPR ，在许多项目中安全性常常被忽略，并且有时选择技术时没有考虑到可持续性。 但是低代码解决方案加剧了这些问题。

有趣的是，低代码是更广泛技术的一部分。 它们以“快速应用程序开发”（RAD）工具和框架开始，以“无代码”（也就是功能较少的无代码替代品）结束。 像Spring Roo这样的代码生成工具是RAD，OpenXava是RAD框架。 某些低代码工具实际上可以看作是RAD工具-开发人员团队可以很容易地使用上述WaveMaker来快速交付较简单的项目，而无需牺牲过多的控制权（我想这是由软件开发公司收购的）。

然后是RPA，即“机器人流程自动化”，我将直截了当简化为“屏幕抓取的低代码”，您可以使涉及旧系统的某些流程自动化，而这些流程只能通过按下“机器人”来提取信息并执行操作。屏幕上的按钮。 RPA稍微不在快速的应用程序开发范围之内，但它带来了一个重要的点-有RPA开发人员。 技术水平不高且不具备开发人员资格的人员，但仍可以使用RPA工具使流程自动化。 低代码和某些RAD风格也是如此-假定您不必一定要开发某些技术，但是实际上可以（并且有）专门的专家可以使用这些工具来构建内容。 他们不是真正的开发人员，但是如果您可以交付一个由5个低代码开发人员和一个实际开发人员组成的项目，则可以大大降低成本。

开发人员和大公司当然拥有一个“工具箱”，它们可以在项目之间重复使用–到处都是片段，有时是一些库或微服务。 但是每个新项目都涉及很多样板，甚至开发人员都需要摆脱这些样板。 我当然不是代码生成的忠实拥护者，但是RAD具有一些优点，我们必须对其进行探索，以便在不牺牲质量的情况下提高效率。 并能够提供简单的工具，否则这些工具将使用次优的低代码方法构建。

但是，已经模糊了“开发人员”和“非开发人员”之间的界限。 在关注我们的框架时，我们不应该对技术欠佳的工具有所了解。 如果仅仅是因为存在风险，从长远来看，我们将不得不为他们提供支持。 而且因为它们将成为我们软件必须与之交互的软件生态系统的一部分。

我不知道这是否是正确的，可持续的数字化转型方法。 当然，我希望每个人都能够在高级RAD工具的帮助下至少编写简单的代码。 而且我们可能会在几十年内到达那里。 但是，由于现在需要进行数字化转型，因此我们可能必须使用已有的东西，并尝试使其更安全，合规，减少供应商锁定并为IT部门提供更多可见性。 否则，我们有可能造成比现在更大的混乱局面。

翻译自: https://www.javacodegeeks.com/2020/05/low-code-rapid-application-development-and-digital-transformation.html

小程序转换纯数字数字