2024年低代码开发趋势报告

欢迎信

作者：Lucy Marcum, DZone组稿编辑

我偶然进入了科技世界。尽管我毕业于一所以其计算机科学项目闻名的大学，但我从未想过自己会与开发人员一起工作------直到毕业后与一位朋友讨论可能的职业道路时。科技世界对我来说曾经如此陌生，但在她的鼓励和我那令人紧张的人脉拓展努力下，我找到了在这个行业的第一份工作。

在最初的几个月里，一切都感觉极其陌生。像Kubernetes 和NoSQL这样的术语让我困惑不已，我大部分时间都沉浸在研究中，学习在新职位上取得成功所需了解的一切。

当时我没有意识到的是，我已经以不同的形式接触过软件开发：低代码和无代码。为了几个大学项目，我使用无代码构建器创建网站来展示研究或概念，偶尔也涉足代码进行自定义调整（在大量搜索之后）。

现在，即使多年后对开发有了概念性的理解，我仍然不声称自己是开发人员。但我确实认识到让非开发人员能够接触开发的重要性。正如我需要在工作中向其他团队寻求帮助一样，开发人员也需要帮助。

赋能非开发人员参与与其任务相关的开发，使得开发人员有时间专注于能产生更大组织影响的更大问题和项目。

将我曾使用的无代码工具与某种形式的软件开发联系起来，是让我的工作感觉易于上手的关键。我知道你们中的许多开发人员读到这儿可能笑了，但有时，正是像第一个"顿悟"时刻这样的小事，能让人在新环境中感到舒适。另一方面，当开发人员意识到通过这些工具所能获得的支持时，他们可能会发现自己的工作流程变得更加顺畅高效。

在DZone的《2024年低代码开发趋势报告》中，我们探讨了低代码在当今开发环境中的重要性。特别是"主要研究发现"部分，回顾了采用情况、自动化、AI的角色以及对开发人员的影响------包括关于谁可以被视为开发人员的一个令人惊讶的混合反应。本趋势报告还包括DZone几位专家社区成员的文章，他们讨论了最佳实践、低代码与AI之间的界限、智能测试策略、公民开发和可扩展性。

祝编码愉快（各种形式的编码），

Lucy

Lucy Marcum
Lucy负责DZone出版物的组稿流程和策略，从寻找新的投稿人和社区成员到引导他们完成编辑审查。她还编辑出版物，创建趋势报告的各个组成部分，并与网站内容和社区团队合作。工作之余，Lucy把时间花在阅读、写作、跑步上，并努力不让她的猫Olive和Tiger Lily惹麻烦。

主要研究发现

DZone 2024低代码开发调查结果分析

作者：G. Ryan Spain, 自由软件工程师，前DZone工程师兼编辑

低代码、无代码、公民开发、AI自动化、可扩展性------如果你在科技界工作，你很可能会被鼓励使用至少其中一个领域的工具。这是有充分理由的，因为Gartner预测，到2025年，组织内开发的应用程序中有70%将使用低代码和/或无代码技术构建。那么，实践是否不负众望呢？

年复一年，随着行业的不断发展，答案是响亮的"是"。组织对更频繁的应用程序发布和更新的需求增加，随之而来的是对提高效率的需求。而这正是低代码和无代码开发实践大放异彩的地方。将AI自动化融入低代码和无代码开发中，可扩展性和机遇是无限的。

五月，DZone对软件开发人员、架构师和其他IT专业人士进行了调查，旨在深入了解低代码开发在软件开发领域的现状。

在这些发现中，我们考察了开发人员对低代码和无代码开发的看法、他们使用和利用低代码工具的方式，以及他们对低代码影响软件开发的经验。

方法

我们创建了一项调查，并将其分发给全球的软件专业人士。问题格式主要包括单项和多项选择，在某些情况下提供填写回答的选项。本次调查通过电子邮件分发给DZone和TechnologyAdvice的注册订阅用户列表，同时在DZone官网、DZone Core Slack工作区及各社交媒体渠道进行了推广。

本报告的数据收集自2024年5月3日至2024年5月23日期间提交的调查回复；我们收集了228份完整和部分回复。

样本特征

我们在下面注明了某些关键的受众细节，以便对得出结果的样本建立更牢固的印象：

29%的受访者将其在组织中的主要角色描述为"开发人员/工程师"，18%描述为"技术架构师"，14%描述为"开发团队负责人"，10%描述为"顾问/解决方案架构师"。我们提供的其他角色均未被超过10%的受访者选择。*
70%的受访者表示他们目前正在开发"Web应用程序/服务（SaaS）"，54%表示"企业业务应用程序"，27%表示"原生移动应用"。
"Java"（72%）是受访者公司使用的最流行的语言生态系统，其次是"JavaScript（客户端）"（54%）、"Python"（53%）、"Node.js（服务器端JavaScript）"（45%）、"TypeScript"（41%）和"C#"（30%）。
关于受访者工作中使用的主要语言的回答，最流行的是"Java"（37%），其次是"Python"（17%）、"C#"（7%）和"Go"（6%）。其他语言的选择率均未超过5%。
平均而言，受访者表示他们拥有17.99年的IT专业人士经验，中位数为18年。
35%的受访者在员工人数<100的组织工作，25%在员工人数100-999的组织工作，38%在员工人数1000+的组织工作。

注：为简洁起见，在本发现报告的其余部分，我们将使用术语"开发人员"或"开发者"来指代任何积极参与软件创建和发布的人员，无论其角色或头衔如何。此外，我们将"小型"组织定义为员工人数<100，"中型"组织定义为员工人数100-999，"大型"组织定义为员工人数1000+。

主要研究目标

在我们的2024年低代码开发调查中，我们旨在收集与以下主要研究目标相关的各种主题的数据：

开发人员对低代码的感受
开发人员如何使用低代码或与低代码交互
低代码对开发和软件质量的影响

在本报告中，我们回顾了一些关键的研究发现。许多感兴趣的次要发现未包含在此处。

研究目标一：开发人员对低代码的感受

首先，我们想看看开发人员对低代码采用如何融入整体开发格局的看法，低代码如何影响开发过程，以及他们认为低代码在哪些方面（如果有的话）可以表现出色。我们还旨在找出参与调查的开发人员类型，无论是前端、后端、全栈还是公民开发者。

在本节中，我们探讨：

受访者如何描述自己作为开发人员
开发人员是否认为"无代码"是"低代码"的子集
开发人员是否认为低代码用户也是"开发人员"
开发人员关于低代码平台如何影响开发过程的看法
开发人员认为哪些用例最适合低代码

受访者如何描述自己作为开发人员

从"AWS解决方案架构师"到"Zapier工程师"，世界上软件专业人士的种类比我们可能开始列举的还要多，一个开发人员可能会根据他们当前正在进行的项目、他们正在与谁交谈、他们希望深入探讨其角色细节的程度等，声称自己属于任何数量的IT相关类别。尽管如此，拥有某些广泛的类别来对我们自己进行分组可能是有用的------不仅是为了便于澄清，也是为了庆祝相似性和欣赏差异性。

在我们的调查中，我们希望明确区分的一个分类是受访者在少数几个"角色"之间的自我认同："前端"、"后端"、"全栈"和"公民"开发者。我们从这里开始，不是因为结果本身说明了开发人员对低代码的感受，而是因为我们将在这些发现中持续引用这些数据。我们询问受访者：

您会如何最好地描述自己？

结果：

图1. 自我描述的开发人员类型 [n=220]

（图表数据翻译：）

后端开发者：39%
全栈开发者：37%
其他，请填写：14%
公民开发者：7%
前端开发者：3%

观察

考虑到我们典型的企业开发人员受众，绝大多数受访者将自己描述为"后端开发者"（39%）或"全栈开发者"（37%）并不奇怪，其中7%将自己描述为"公民开发者"，只有3%将自己描述为"前端开发者"。14%的受访者选择了"其他，请填写"，填写选项包括"架构师"、"经理"、"数据工程师"和"测试工程师"。
这些结果与我们2023年Web、移动和低代码开发调查收集的结果非常相似。"后端开发者"的回复率与2023年相比保持不变，"前端开发者"和"公民开发者"的回复率变化在统计上不显著。"全栈开发者"的回复率略有下降，同时选择"其他，请填写"选项的受访者有所增加。
我们预计这些轻微的逐年变化归因于样本特征的变化（例如，去年38%的受访者将其在组织中的主要角色描述为"开发人员/工程师"，而今年为29%）以及普遍存在的抗拒"把自己框定"的心态。按年份划分的结果详情见表1。

表1. 自我描述的开发人员类型：2023年 vs. 2024年

| 开发人员类型 | 2023 | 2024 |

| :--- | :--- | :--- |

| 后端 | 39% | 39% |

| 全栈 | 45% | 37% |

| 公民 | 3% | 7% |

| 前端 | 8% | 3% |

| 其他 | 4% | 14% |

就其本身而言，从这个问题的回答收集的数据表明------毫不奇怪------企业中很少有软件专业人士认为自己是公民开发者。逐年的结果可能预示着未来企业软件中公民开发者数量的增长，但即使如此，似乎在未来许多年也不太可能出现显著增长。正如我们之前提到的，这个问题的结果主要是在用于按开发人员类型细分其他回答时才引起兴趣。由于"公民"、"前端"和"填写"选项的回复率较低，在本发现报告的剩余部分，我们将把这个问题回答分组为"后端"、"全栈"和"非后端/全栈"。

低代码、无代码与"开发人员"头衔

开发人员可能非常保护他们的技能组合，并警惕那些他们认为试图在没有适当考虑软件创建所有方面的情况下强行进入开发领域的人。通常，这些感觉并非源于试图设限，而是源于制作拙劣的软件可能产生深远的后果。

构建一个实现预期目标的函数不一定困难，但理解该函数对系统稳定性、性能和安全性影响则完全是另一回事，更不用说概念化该函数在未来系统扩展时的需求和影响了。因此，低代码对于一些开发人员来说可能是一个有争议的话题，为了了解更多他们的看法，我们询问：

*您个人是否认为"无代码"开发是"低代码"开发的一个子集？

同意/不同意："开发人员"头衔也应适用于仅使用低代码工具创建应用程序且可能从未自己编写任何代码的人。*

结果：

图2. "无代码"是"低代码"吗？[n=219]

（图表数据翻译：）

是：53%
否：32%
无意见：16%

图3. 严格使用低代码的用户应该拥有"开发人员"头衔吗？[n=210]

（图表数据翻译：）

中立：28%
不同意：20%
同意：19%
非常不同意：17%
非常同意：16%

观察

大约一半的受访者（53%）认为无代码属于低代码范畴，而32%认为这两个概念是分开的，16%对此事没有意见。
大约相同比例的后端开发者和全栈开发者认为无代码是低代码的子集，尽管后端开发者比全栈开发者更可能"无意见"，并且比全栈开发者更不可能回答他们不认为无代码是低代码的一部分。非后端/全栈开发者最可能认为无代码包含在低代码中，并且最不可能回答"无意见"。这些结果的详细信息见表2。

表2. "无代码"是"低代码"吗？（按开发人员类型细分）*

| 回复 | 开发人员类型 |

| :--- | :--- | :--- | :--- |

| | 后端 | 全栈 | 非后端/全栈 |

| 是 | 49% | 51% | 62% |

| 否 | 28% | 36% | 31% |

| 无意见 | 22% | 14% | 8% |

*列为百分比

在后面的发现中，我们讨论了表明全栈开发者比后端开发者更频繁地使用低代码的数据。那么，全栈开发者对"低代码"和"无代码"区分更明确的看法，可能基于这种额外的熟悉度。也许他们的经验表明，"无代码"解决方案通常比"低代码"平台提供更少的灵活性和定制化，而低代码平台允许开发者根据需要扩展和定制应用程序。
受访者对于是否应将可能从未编写任何实际代码的低代码工具用户视为"开发人员"存在相当分歧：大约三分之一的受访者倾向于同意这一观点（35%），大约三分之一不同意（37%），大约三分之一保持中立（28%）。后端开发者比全栈工程师更可能不同意或强烈不同意这类低代码用户应被称为"开发人员"（44% vs 32%），而全栈开发者比后端开发者更可能同意或强烈同意（39% vs 28%）。

低代码 vs. 全代码：关于开发过程的看法

在某些情况下，低代码和全代码的软件创建方法可能被视为旨在实现相同目标的两种方法。在其他情况下，低代码工具可能被认为适用于某些目标，而全代码开发适用于其他目标。我们想知道开发人员对于使用低代码工具创建的软件与完全编码的软件在复杂性、可重用性和开发易用性方面的根本差异的看法，因此我们提出了以下问题：

*您认为使用低代码工具构建的应用程序相对于完全用代码编写的应用程序应该有多复杂？

在您看来，调试低代码应用程序或与低代码应用程序交互的软件是...

在您看来，使用低代码工具实现的业务逻辑是...

在您看来，使用低代码平台构建的软件会导致...*

结果：

图4. 关于低代码 vs. 全代码应用程序复杂性的看法 [n=220]

（图表数据翻译：）

稍微简单一些：39%
简单得多：19%
与全代码应用程序一样复杂：16%
稍微复杂一些：11%
无意见：9%
复杂得多：3%

图5. 关于低代码 vs. 全代码调试易用性的看法 [n=218]

（图表数据翻译：）

更难：25%
更容易：22%
无意见：19%
可能更难：19%
可能更容易：9%

图6. 关于低代码 vs. 全代码业务逻辑可重用性的看法 [n=211]

（图表数据翻译：）

可重用性更低：36%
可重用性更高：39%
可重用性相同：17%
无意见：8%

图7. 关于低代码 vs. 全代码产生的技术债务的看法 [n=219]

（图表数据翻译：）

技术债务更少：31%
技术债务相同：21%
技术债务更多：21%
可能技术债务更少：13%
可能技术债务更多：9%
无意见：5%

观察

大多数受访者（68%）认为使用低代码工具构建的应用程序应该至少"稍微简单一些"，而很少（14%）认为低代码驱动的应用程序应该至少"稍微复杂一些"。这些回复率与我们上次在2022年低代码开发调查中提出这个问题时看到的比率相似，当时我们看到62%的人说使用低代码工具创建的软件应该至少"稍微简单一些"，17%的人说应该至少"稍微复杂一些"。

低代码平台 设计为用户友好型并能实现快速开发，这可能导致人们认为它们更适合简单的应用程序------开发人员可能觉得这些工具抽象掉了传统编码涉及的许多复杂性 。此外，全代码应用程序提供了更大的灵活性和定制选项，允许开发人员创建更复杂和量身定制的解决方案。低代码工具在提供的定制深度方面可能被视为有限。低代码工具不太可能很快弥合复杂性差距------至少在大多数开发人员心目中是这样。

受访者对于调试低代码应用程序比传统代码调试更容易还是更困难存在分歧，但总体而言，认为低代码软件更难调试或可能比全代码应用程序更难调试的受访者（44%）多于认为调试低代码更容易或可能更容易的受访者（31%）。

一些开发人员可能发现低代码应用程序更难调试 ，因为抽象和对底层代码的有限可见性掩盖了问题的根本原因 并限制了直接操作。生成代码的专有性质和不熟悉的调试工具进一步使过程复杂化。另一方面，一些开发人员可能发现低代码应用程序更容易调试 ，因为低代码平台通常提供集成的调试工具、可视化界面和标准化环境，简化了错误识别和解决。低代码开发的可视化性质可以增强对应用程序逻辑的理解并减少编码错误，使一些开发人员更容易诊断和修复问题。

受访者主要在认为低代码业务逻辑比代码实现的业务逻辑可重用性更高还是更低之间存在分歧，认为两者具有相同可重用性水平和无意见的受访者子集要小得多。认为低代码业务逻辑可重用性更低的回复率与2022年保持不变，但认为低代码业务逻辑可重用性更高的回复率从2022年的30%增加了9%，而认为低代码和全代码业务逻辑具有相同可重用性水平的回复率从28%下降了11%。

认为低代码业务逻辑比全代码可重用性更高 的开发者可能这样认为，是因为低代码平台的模块化组件、拖放界面和内置模板促进了业务逻辑在不同应用程序间的轻松复制和适应------这些方面可以增强一致性并加速开发周期。他们也可能认为非开发人员或公民开发者更容易利用某些低代码业务逻辑，从而允许在组织内更广泛地重用。

相反，其他开发人员可能认为低代码业务逻辑可重用性更低 ，因为许多低代码平台的专有性质，在与其他系统或平台集成时可能产生兼容性问题和限制灵活性 。或者他们可能认为低代码业务逻辑是脆弱的，是为一次性目的创建的，没有考虑如何设计和实现逻辑以最大化其可重用性。

与两年前相比，现在更多的开发人员可能认为低代码业务逻辑可重用性更高 ，这是因为低代码技术的进步、集成能力的提高以及低代码环境中标准化实践的日益普及，这些共同增强了重用低代码组件的吸引力和实用性。

最后，更多受访者认为使用低代码平台创建的软件导致（或可能导致）比用代码编写的软件更少的技术债务（44%），相比之下，认为会导致更多技术债务（30%）或相同数量技术债务（21%）的受访者要少。这些结果与我们在2022年看到的结果一致，逐年结果没有显著变化。

开发人员可能认为使用低代码平台构建的软件导致更少的技术债务 ，因为这些平台强制执行标准化的编码实践，可以减少手动编码错误，并提供预构建的组件以确保一致的质量和可维护性。这些特性可以最大限度地降低编写不良代码的风险，并使更新和扩展应用程序变得更加容易。再者，非开发人员或公民开发者能够为软件需求做出贡献，可能通过释放开发团队周期用于更复杂或关键的问题来帮助减轻技术债务。

另一方面，一些开发人员可能认为低代码平台缺乏对软件系统的灵活性和控制 ，这可能导致低效和变通方法，使未来的维护复杂化。此外，对专有技术的依赖可能产生难以管理或替换的依赖性，从而增加长期技术债务。

有价值的低代码用例

在继续考察开发人员对低代码的看法时，我们想知道受访者认为哪些类型的功能适合使用低代码工具构建，并询问：

在您看来，低代码平台对哪些用例有用？

结果：

图8. 被认为有用的低代码用例 [n=218]

（图表数据翻译：按选择百分比排序）

交互式网页表单：66%
业务流程自动化：56%
企业CRUD：54%
简单数据库：51%
请求处理：43%
业务流程管理：43%
集成中间件：39%
学习管理：29%
机器人流程自动化/AI自动化：29%
BI/数据分析：28%
电子商务和电子采购：27%
ETL：22%
机器学习管道：18%
安全流程：15%
物理建模：12%
其他，请填写：6%

观察

与开发人员对使用低代码工具构建的应用程序/组件复杂性的感受一致，受访者认为低代码平台有用的最流行用例通常是低复杂性、低风险的软件元素。超过一半的受访者认为"交互式网页表单"、"业务流程自动化"、"企业CRUD"和"简单数据库"是低代码的合适用例，而很少受访者对"物理建模"、"安全流程"和"机器学习管道"等用例持相同看法。

截至目前，低代码工具更常被认为擅长构建 涉及重复性、定义明确任务的应用程序，这些任务可以受益于平台的快速开发能力、预构建组件和用户友好界面。这些用例通常需要较少的复杂逻辑和定制，使它们成为低代码解决方案的理想选择。

相反，更高复杂性的软件被认为不太适合 低代码平台，因为它们通常需要高级的、专门的算法 、高水平的定制以及严格的性能和安全性标准，而低代码工具可能难以满足这些要求，特别是如果软件旨在由几乎没有软件设计经验的员工创建。这些复杂应用程序所需的固有灵活性和控制更好地由传统的编码方法提供。

我们将在后面的发现中考察受访者实际利用低代码平台的用例。

这个问题的结果大多与我们2023年上次提出该问题时看到的结果一致。逐年回复率唯一具有统计学显著变化的是"交互式网页表单"、"请求处理"和"集成中间件"的增加，以及"ETL"的减少。这些结果的详细信息见表3：

表3. 被认为有用的低代码用例：2023-2024*

| 用例 | 2023 | 2024 | 变化百分比 |

| :--- | :--- | :--- | :--- |

| 交互式网页表单 | 58% | 66% | +8% |

| 业务流程自动化 | - | 56% | - |

| 企业CRUD | 52% | 54% | +2% |

| 简单数据库 | 56% | 51% | -5% |

| 请求处理 | 36% | 43% | +7% |

| 业务流程管理 | 48% | 43% | -5% |

| 集成中间件 | 28% | 39% | +11% |

| 学习管理 | 28% | 29% | +1% |

| 机器人流程自动化/AI自动化 | - | 29% | - |

| BI/数据分析 | - | 28% | - |

| 电子商务和电子采购 | 24% | 27% | +3% |

| ETL | 32% | 22% | -10% |

| 机器学习管道 | 16% | 18% | +2% |

| 安全流程 | - | 15% | - |

| 物理建模 | 10% | 12% | +2% |

| n= | 93 | 218 | |

*注：2023年列中的空白表示我们2024年调查中添加的选项。

总体而言，这些数据表明开发人员对低代码用例的看法变化缓慢，并且低代码平台可能需要取得重大进步，大多数开发人员才会对将低代码用于更复杂的软件需求感到满意。

研究目标二：开发人员如何使用低代码或与低代码交互

随着组织采用低代码平台，越来越多的开发人员很可能需要以某种方式与低代码合作。这可能意味着为低代码创建的功能设计和构建互操作性。或者它可能涉及学习并使用新的低代码平台本身。我们想了解更多关于开发人员与低代码工具交互的现状。

在本节中，我们讨论：

开发人员如何与低代码软件交互或使用低代码工具构建
开发人员如何使用低代码进行自动化和AI

与低代码软件交互和构建

全代码软件开发人员可能需要与低代码平台交互的原因有很多，例如：

集成低代码工具无法提供的自定义功能
将低代码应用程序与其他系统和服务连接，处理复杂的集成并确保整个企业的无缝数据流
维护和排查低代码应用程序故障，解决需要更深入了解底层代码和系统架构的性能问题或错误

我们想找出开发人员处理低代码的频率，因此我们提出了以下问题：

*您编写与使用低代码平台构建的软件交互的代码的频率如何？

您使用低代码平台构建软件的频率如何？*

对于回答并非"从未"使用低代码平台构建软件的受访者，我们还询问：

您使用低代码平台实现了哪些类型的软件或软件功能？

结果：

图9. 编写与低代码创建软件交互代码的频率 [n=220]

（图表数据翻译：）

有时：32%
很少：26%
经常：20%
从未：13%
一直：10%

图10. 使用低代码平台创建软件的频率 [n=215]

（图表数据翻译：）

有时：30%
很少：25%
经常：19%
从未：16%
一直：10%

图11. 使用低代码平台实现的软件/功能类型 [n=175]

（图表数据翻译：按选择百分比排序）

交互式网页表单：46%
企业CRUD：37%
业务流程自动化：39%
简单数据库：27%
集成中间件：27%
业务流程管理：31%
请求处理：24%
机器人流程自动化/AI自动化：15%
BI/数据分析：12%
电子商务和电子采购：14%
ETL：13%
学习管理：11%
安全流程：8%
物理建模：6%
机器学习管道：5%
其他，请填写：4%

观察

几乎所有受访者（93%）都至少有一些与使用低代码平台构建的软件交互或自己使用低代码平台构建的经验（即，他们至少回答了其中一个问题，并且没有对两个问题都回答"从未"）。总体而言，受访者使用低代码工具构建的可能性与低代码构建软件交互的可能性一样高，并且个体受访者倾向于以相同的频率进行其中一项活动。

例如，大多数表示他们"一直 "与低代码工具创建的软件交互的受访者也表示他们"一直 "使用低代码构建软件，对于"经常 "、"有时"等也是如此（详情见表4）。

表4. 与低代码构建软件交互的频率和使用低代码构建的频率*

| | 使用低代码构建 |

| :--- | :--- | :--- | :--- | :--- | :--- | :--- |

| 与低代码交互 | 一直 | 经常 | 有时 | 很少 | 从未 | 总体 |

| 一直 | 55% | 30% | 10% | 5% | 0% | 10% |

| 经常 | 9% | 63% | 12% | 9% | 7% | 20% |

| 有时 | 4% | 7% | 64% | 15% | 9% | 32% |

| 很少 | 2% | 4% | 18% | 57% | 20% | 26% |

| 从未 | 7% | 3% | 14% | 24% | 52% | 13% |

| 总体 | 10% | 19% | 30% | 25% | 16% | |

*行内百分比

这些结果可能表明，采用低代码技术的组织通常在整个组织范围内同等程度地使用它们，而不是将这些工具的使用隔离给公民开发者或非开发团队。我们将在研究目标三中讨论受访者关于低代码如何影响软件质量的经验。

将自己描述为全栈开发者的受访者频繁（"经常"或"一直"）使用低代码平台构建软件的可能性显著高于后端和非后端/全栈开发者。非后端/全栈开发者最可能说他们"有时"使用过低代码平台，而后端开发者最可能说他们"很少"或"从未"使用过低代码。具体数据见表5。

表5. 按开发人员类型划分的低代码使用频率*

| 频率 | 开发人员类型 |

| :--- | :--- | :--- | :--- | :--- |

| | 后端 | 全栈 | 非后端/全栈 | 总体 |

| 一直 | 4% | 18% | 8% | 10% |

| 经常 | 13% | 27% | 17% | 19% |

| 有时 | 29% | 23% | 40% | 29% |

| 很少 | 36% | 19% | 17% | 25% |

| 从未 | 18% | 14% | 17% | 16% |

*列内百分比

对于每个用例，声称曾利用低代码平台实现该功能用例的受访者，认为低代码是处理该用例的合适工具的可能性远高于总体受访者。例如，虽然总体上有54%的受访者认为低代码平台对"企业CRUD"有用，但声称实际使用低代码进行"企业CRUD"的受访者中有90%持相同看法。我们提供的每个用例答案选项，在实际使用低代码处理该用例的受访者中，关于低代码对该用例有用性的回复率都有显著增加。详情见表6。

表6. 按用例划分的低代码有用性看法：报告的低代码使用情况 vs. 总体比率

| 用例 | 使用过此用例 | 总体 | 差值 |

| :--- | :--- | :--- | :--- | :--- | :--- |

| | 比率 | n= | 比率 | n= | |

| 机器人流程/AI自动化 | 93% | 26 | 29% | 63 | 64% |

| 企业CRUD | 90% | 64 | 54% | 117 | 36% |

| 简单数据库 | 87% | 47 | 51% | 111 | 36% |

| 交互式网页表单 | 87% | 80 | 66% | 143 | 21% |

| 业务流程自动化 | 86% | 69 | 56% | 121 | 31% |

| 电子商务和电子采购 | 86% | 25 | 27% | 59 | 59% |

| 学习管理 | 83% | 19 | 29% | 64 | 53% |

| 请求处理 | 82% | 42 | 43% | 94 | 39% |

| 安全流程 | 82% | 14 | 15% | 32 | 68% |

| 业务流程管理 | 82% | 54 | 43% | 94 | 39% |

| BI/数据分析 | 78% | 21 | 28% | 62 | 49% |

| 集成中间件 | 77% | 47 | 39% | 86 | 38% |

| ETL | 72% | 23 | 22% | 48 | 50% |

| 机器学习管道 | 67% | 8 | 18% | 39 | 49% |

| 物理建模 | 63% | 10 | 12% | 27 | 50% |

| 其他，请填写 | 58% | 7 | 6% | 12 | 53% |

尽管这些结果可能反映了某些认知偏差，例如单纯曝光效应，但这些偏差的证据可能表明低代码工具比许多开发人员认为的更具实用性，并且组织采用低代码平台的增加可能导致开发人员在有机会尝试这些工具后找到更多使用它们的方法。

用于自动化和AI的低代码

自动化和AI都是利用低代码能力的有前景的领域。两者都有潜力简化各种重复性任务，使员工能够减少花在繁忙工作上的时间，而将更多时间用于运用他们的技能组合。低代码平台可以使业务用户和开发人员都能够以最少的编码创建和修改自动化工作流以及AI驱动的流程 。低代码平台的可视化界面和预构建组件可以更轻松地将AI能力------如机器学习模型和自然语言处理------集成到业务应用程序中，从而提高运营效率和决策能力。为了确定组织目前如何使用低代码进行自动化和AI，我们提出了以下问题：

您的组织是否使用低代码工具来创建工作流和/或流程自动化？

对于回答"是"或"否，但我们正在考虑"的受访者，我们还询问：

您使用或正在考虑使用以下哪些工作流和/或流程自动化方法？

关于用于AI的低代码，我们询问：

您的组织在哪些用例中使用低代码AI工具或平台？

结果：

图12. 组织使用低代码进行工作流/流程自动化的情况 [n=213]

（图表数据翻译：）

是：47%
否，我们也没有考虑：18%
我不知道：11%
否，但我们正在考虑：24%

图13. 使用或考虑的工作流/流程自动化方法 [n=150]

（图表数据翻译：按选择百分比排序）

业务流程管理：65%
机器人流程自动化：42%
企业资源规划：39%
超自动化：15%
其他：5%

图14. 低代码AI工具/平台的使用用例 [n=211]

（图表数据翻译：按选择百分比排序）

聊天机器人/虚拟助手：38%
预测分析：24%
语言处理：22%
计算机视觉：19%
不适用：21%

观察

近一半的受访者（47%）表示他们的组织使用低代码工具进行工作流/流程自动化，这比我们在2023年调查中看到的60%显著下降。回答"否，但我们正在考虑"的回复率从2023年的11%增加到24%以作补偿，而回答"否，我们也没有考虑"和"我不知道"的回复率在2023年和2024年之间没有显著变化。

考虑到我们在比较本次调查中其他问题的逐年结果时没有看到低代码工具使用率的下降，目前尚不清楚为什么今年声称其组织使用低代码工具进行工作流和/或流程自动化的受访者如此之少，但这是我们未来继续低代码研究时将关注的趋势。

大多数在使用或考虑使用低代码进行工作流/流程自动化的组织的受访者也表示，他们使用或考虑使用"业务流程管理"，尽管这一数字也低于我们2023年收集的结果。另一方面，"机器人流程自动化"和"企业资源规划"的回复率较2023年调查结果有所增加。逐年数据见表7：

表7. 使用或考虑的工作流/流程自动化方法：2023-2024

| 方法 | 2023 | 2024 | 变化百分比 |

| :--- | :--- | :--- | :--- |

| | 比率 | n= | 比率 | n= | |

| 业务流程管理 | 75% | 49 | 65% | 97 | -10% |

| 机器人流程自动化 | 28% | 18 | 42% | 63 | +14% |

| 企业资源规划 | 31% | 20 | 39% | 58 | +8% |

| 超自动化* | - | - | 15% | 22 | - |

| 其他 | 11% | 7 | 5% | 8 | -6% |

*注："超自动化"是我们为2024年调查添加的回复选项。

这些结果可能表明，使用低代码进行工作流/流程自动化的组织正在扩展他们采用的方法。

大多数受访者（63%）表示他们的组织将低代码AI工具用于至少一个列出的用例------最流行的用例是"聊天机器人/虚拟助手"。
小型组织的受访者声称其组织使用低代码AI工具的可能性要低得多，有34%选择"不适用"，而中型组织的受访者为12%，大型组织为14%。
小型组织的受访者声称其组织使用低代码处理"聊天机器人/虚拟助手"（23%）和"预测分析"（8%）的可能性显著低于中型组织（分别为40%和27%）和大型组织（分别为47%和27%）的受访者。
有趣的是，小型组织的受访者声称其组织使用低代码AI进行"语言处理"（24%）的可能性高于中型组织（15%），但仍低于大型组织（31%）。

研究目标三：开发人员如何看待低代码对开发和软件质量的影响

我们在研究发现中试图至少触及的一个主要问题是："这个主题的影响是否与其周围的炒作相符？"换句话说，我们想知道我们讨论的主题是否对软件开发整体产生积极影响。为此，我们在本节中考察：

低代码对软件质量的影响
低代码安全关切以及对低代码治理的需求

低代码对软件质量的影响

在本报告的第一个研究目标中，我们考察了开发人员对低代码影响开发的感受和看法。我们还希望考察开发人员对使用低代码工具的开发过程和软件的第一手经验------这个区别可能很小，但我们认为很重要。

在这里，我们考察的是那些报告至少有一些与低代码创建软件交互或自己使用低代码工具构建应用程序经验的开发人员（正如我们之前看到的，他们占受访者的93%）的回答，提出以下问题：

*根据您的经验，使用低代码工具总体上使软件...*

根据您的经验，使用低代码工具是否使开发更具迭代性？*

根据您的经验，使用低代码工具导致总体上...**

结果：

图15. 低代码对软件性能、可维护性、可扩展性和安全性的影响 [n=199]

（图表数据翻译：针对每个属性，显示"更好"、"大致相同"、"更差"的百分比）

性能：更好 26%，大致相同 40%，更差 25%
可维护性：更好 47%，大致相同 30%，更差 17%
可扩展性：更好 40%，大致相同 32%，更差 21%
安全性：更好 38%，大致相同 35%，更差 20%

图16. 低代码对开发迭代性的影响 [n=196]

（图表数据翻译：）

是：53%
否：25%
无意见：22%

图17. 低代码对软件质量的影响 [n=197]

（图表数据翻译：）

更高质量的软件：41%
相同质量的软件：28%
更低质量的软件：24%
无意见：7%

*注：这三个问题仅询问了未在"您使用低代码平台构建软件的频率如何？"问题中回答"从未" 或未在"您编写与使用低代码平台构建的软件交互的代码的频率如何？"问题中回答"从未"的受访者。

观察

可维护性是受访者最可能表示被低代码改进的特性，尽管认为低代码工具改善了可扩展性和安全性的受访者也占多数。受访者最可能说低代码构建的软件性能与全代码应用程序大致相同，而表示低代码使软件性能"更好"或"更差"的受访者数量大致相当。

表示最频繁（"经常"或"一直"）使用低代码工具构建软件的受访者，比其他受访者更可能发现低代码使软件性能更好（36%）、更可维护（65%）、更可扩展（53%）和更安全（55%）。

略多于半数的受访者认为低代码工具使软件开发更具迭代性。这些结果与我们2022年收集的结果相比没有显著变化。

再次，报告"经常"或"一直"使用低代码工具构建软件的受访者，比那些"有时"使用低代码工具构建（60%）和那些"很少"或"从未"使用低代码工具构建（36%）的受访者更可能发现使用低代码使开发更具迭代性（74%）。

由于许多低代码平台是专门为支持快速原型设计和快速修改而设计的，允许开发人员根据即时反馈持续完善和改进应用程序，这些结果符合预期。我们再次看到，更广泛地使用低代码工具的经验会带来对其潜力的更积极看法。

显著更多的受访者表示，他们的经验表明低代码工具导致了更高质量的软件，而不是表示低代码导致相同或更低质量软件的受访者，尽管他们并未形成多数。

虽然这些结果与我们2023年调查收集的结果有显著不同，但它们已恢复到我们在2021年低代码开发和2022年低代码开发调查中看到的比率（详情见表8）。目前尚不清楚去年是什么可能影响了低代码构建软件感知质量的下降。

表8. 低代码对软件质量的影响：2021-2024

| 影响 | 2021 | 2022 | 2023 | 2024 |

| :--- | :--- | :--- | :--- | :--- |

| 更高质量的软件 | 39% | 38% | 22% | 41% |

| 相同质量的软件 | 26% | 28% | 24% | 28% |

| 更低质量的软件 | 24% | 25% | 32% | 24% |

| 无意见 | 11% | 10% | 22% | 7% |

再次，使用低代码"经常"或"一直"构建软件的受访者，经历低代码工具允许创建更高质量软件的可能性（61%）远高于那些"有时"使用低代码构建软件（37%）或"很少"/"从未"使用（27%）的受访者。我们认为这与低代码平台可以允许的迭代性密切相关，如前一观察所述。

低代码安全与治理

在构建任何类型的软件时，治理和安全性都是至关重要的考虑因素，因此，在处理低代码工具时，这些将是尤其需要观察的重要领域，因为低代码工具可能允许新平台广泛访问应用程序基础设施------并且可能涉及开发团队以外的员工来添加功能或与软件内部交互。我们想找出在低代码使用方面，开发人员最关心治理和安全的哪些方面，因此我们询问：

*在以下选择中，您认为在您组织中建立对低代码工作治理的主要需求是什么？

您认为OWASP低代码/无代码十大安全关切中，哪些是您当前贡献的软件的显著潜在威胁？**

结果：

图18. 建立对低代码工作治理的主要需求 [n=204]

（图表数据翻译：）

管理端到端应用程序开发生命周期：31%
避免冗余应用程序的蔓延：22%
保护免受对其他企业系统和数据的影响：22%
维持企业质量和性能标准的可见性：21%
其他：4%

图19. 构成显著潜在威胁的低代码安全关切 [n=197]

（图表数据翻译：按选择百分比排序）

身份验证和安全通信故障：41%
数据和密钥处理故障：40%
授权滥用：38%
易受攻击和不受信任的组件：35%
安全日志记录和监控故障：33%
注入处理故障：28%
资产管理故障：25%
数据泄漏和意外后果：24%
账户冒充：21%
无：13%

*注：此问题仅询问了未在"您使用低代码平台构建软件的频率如何？"问题中回答"从未" 或未在"您编写与使用低代码平台构建的软件交互的代码的频率如何？"问题中回答"从未"的受访者。

观察

受访者关于建立对低代码工作治理的主要原因的看法在提供的四个选项中分布相当均匀，"管理端到端应用程序开发生命周期"略微领先于其他选项。这些结果与我们2022年调查收集的结果相比没有显著变化。

表示"经常"或"一直"使用低代码平台构建软件的受访者比其他受访者更可能将"维持企业质量和性能标准的可见性"视为低代码治理的主要原因，并且更不可能选择"保护免受对其他企业系统和数据的影响"和"避免冗余应用程序的蔓延"。表示"很少"或"从未"使用低代码工具构建软件的受访者比其他受访者更不可能选择"管理端到端应用程序开发生命周期"作为建立治理的主要需求。此数据的详细信息见表9：

表9. 按使用低代码工具构建软件的频率划分的建立低代码治理的主要需求

| 需求 | 使用频率 |

| :--- | :--- | :--- | :--- |

| 管理端到端应用程序开发生命周期 | 23% | 35% | 37% |

| 维持企业质量和性能标准的可见性 | 24% | 17% | 35% |

| 保护免受对其他企业系统和数据的影响 | 23% | 25% | 15% |

| 避免冗余应用程序的蔓延 | 27% | 23% | 10% |

| 其他 | 4% | 0% | 3% |

没有一个单一的安全关切被认为是对受访者贡献过的软件的"显著潜在威胁"，但四分之三的受访者选择了至少一个他们认为可能证明是严重的关切，大约一半（49%）选择了三个或更多，大约四分之一（24%）选择了OWASP低代码/无代码十大安全关切中的五个或更多。

全栈开发者比其他开发者更可能认为"易受攻击和不受信任的组件"（41%）、"安全日志记录和监控故障"（36%）、"注入处理故障"（31%）和"账户冒充"（26%）是潜在的严重威胁，而非后端/全栈开发者比其他开发者更可能将"授权滥用"（40%）视为可能严重的威胁，并且更不可能将"数据泄漏和意外后果"（31%）和"身份验证和安全通信故障"（15%）视为此类威胁。

表示最频繁使用低代码工具构建软件的受访者比其他受访者更可能发现"注入处理故障"（29%）是严重威胁，并且更不可能相信"授权滥用"（23%）和"账户冒充"（15%）是主要关切。这些受访者也更可能声称OWASP低代码/无代码十大安全关切中没有一个对其软件构成显著威胁（13%）。

表示"很少"或"从未"使用低代码构建软件的受访者比其他受访者更可能选择"资产管理故障"（19%），并且更不可能选择"数据和密钥处理故障"（18%）作为潜在的严重威胁。

未来研究

我们这里的分析仅触及了可用数据的表面，我们将在制作未来的趋势报告时完善和扩展我们的低代码开发调查。我们在本报告中未涉及但已纳入调查的一些主题包括：

开发人员希望业务用户创建简单自动化的意愿
低代码和全代码之间互操作性问题的频率
低代码避免可预防开发错误的能力

通过低代码和无代码集成转变软件开发

创建更快、更智能的软件开发流程

作者：Shantanu Kumar, Amazon 高级软件工程师

尽管传统的软件开发生命周期（SDLC）速度缓慢且无法满足动态的业务需求，但它长期以来一直是公司构建应用程序最流行的方式------直到低代码和无代码（LCNC）工具的出现。这些工具简化了编码过程，使得高级开发人员和非技术用户都可以做出贡献，通过缩短SDLC使组织能够快速响应市场需求。

请继续阅读，了解软件开发如何因LCNC工具而改变，如何将它们集成到您的运营中，以及集成时可能出现的挑战。

理解低代码和无代码开发

低代码和无代码开发环境让人们能够通过可视化界面、拖放工具和可重用组件来构建应用程序，而无需手动编写代码。低代码开发平台是可视化开发环境，使任何技能水平的开发人员都能够将组件拖放到面板上并连接它们以创建移动或Web应用程序。无代码开发平台则面向没有或几乎没有编码经验的用户。

那么，您如何利用这些平台来增强传统的SDLC呢？

假设您是一名具有基本编码技能的设计师。使用LCNC平台，您可以快速使用可重用组件创建原型，而无需编写一行代码。这将加快软件开发过程，并确保最终产品满足用户需求。

低代码和无代码集成的规划与评估

尽管SDLC因不同的SDLC模型而在公司间有所不同，但它通常包括以下阶段：项目规划、需求收集与分析、设计、测试、部署和维护。这个过程确保了高度的细节，但减慢了开发周期并消耗了大量资源。

低代码和无代码工具解决了这一挑战。例如，在设计阶段，人力资源团队可以使用LCNC平台提供的可重用组件或预制模板快速设计他们的招聘门户，以轻松跟踪候选人、职位发布和面试安排。

也就是说，在将LCNC平台集成到您现有的工作流之前，请考虑您团队的专长、您选择的平台与您的IT基础设施的兼容性以及平台的安全特性。

低代码和无代码集成的步骤

要将低代码和无代码工具集成到您的运营中，请遵循以下步骤：

图1. 实现无缝LCNC集成的简化步骤

（图表描述：一个循环图，包含以下步骤：1. 定义目标和目的 -> 2. 选择合适的LCNC平台 -> 3. 培训团队成员 -> 4. 设计集成架构 -> 5. 实施集成框架 -> 6. 进行测试和质量保证 -> 7. 管理部署和发布 -> 8. 监控和维护 -> 返回步骤1 形成循环）

表1扩展了这些步骤，并包括每个步骤的示例：

表1. 集成LCNC工具的步骤

| 步骤 | 描述 | 示例 |

| :--- | :--- | :--- |

| 1. 定义目标和目的 | 明确定义您想要实现的目标，并使其具体化。目标可能包括加速开发、降低成本或提高团队生产力。 | 在六个月内使用预构建模板将应用程序开发时间减少40%。 |

| 2. 选择合适的LCNC平台 | 不要将就。评估各种平台，并将其与您的需求和目标相匹配。考虑用户友好性、安全特性以及与现有系统的兼容性。 | 如果大多数团队成员不精通技术，则选择一个主要因其易用性和教育支持而突出的无代码平台。 |

| 3. 培训和引导团队成员 | 确保所有团队成员，无论是否精通技术，都能使用您的平台。 | 安排讲座和网络研讨会，甚至为您的团队成员报名参加LCNC平台提供的专业课程。 |

| 4. 设计集成架构 | 确保您的平台设计得易于与当前系统集成。 | 映射数据在现有系统和首选平台之间的流动方式。 |

| 5. 实施集成框架 | 创建一个在SDLC内集成LCNC平台的框架。在最简单的层面上，这可能涉及为SDLC每个阶段选择工具创建指南。 | 集成LCNC平台以收集客户调查回复、产品发布反馈或联系表单提交。没有这些工具，开发人员需要从头开始构建功能，需要大量的前端开发和存储集成，导致更高的成本和更长的开发周期。 |

| 6. 进行测试和质量保证 | 使用混合测试方法（如单元测试、集成测试和验收测试）对您的LCNC工具进行严格测试。 | 您可以执行验收测试以确保您的应用程序满足最终用户的需求和期望。 |

| 7. 管理部署和发布 | 以结构化的方式使用部署策略（例如，滚动部署）将您的应用程序部署给最终用户，并包含在出现不可预见问题时回滚的计划。 | 您可以使用云解决方案来自动化部署。 |

| 8. 监控和维护 | 部署后监控应用程序的性能以检测潜在的相关问题。 | 在维护期间，您可能会遇到错误。安排定期错误修复可以维护应用程序的稳定性、功能性和安全性。 |

集成低代码和无代码：要实施和避免的实践

虽然低代码和无代码平台简化了SDLC，但实施它们需要结构化的方法。接下来，我们将探讨在集成过程中需要考虑的最佳实践和适得其反的实践。

实施：渐进式采用

将低代码和无代码平台逐步集成到现有的流程和系统中，可以最大限度地减少对正在进行的运营的干扰。首先将LCNC解决方案用于非关键项目，这些项目可以作为完善集成策略的试验场。例如，开发人员可以逐步迁移LCNC流程，从非关键的、易于打包的流程开始，并随着时间的推移逐渐扩大规模。非关键流程，如电子邮件通知，更适合缓慢、迭代地推广到一小部分客户。

实施：协作开发

协作开发是一种强调团队合作的方法论。它将SDLC中涉及的各种利益相关者聚集在一起，例如项目经理、业务分析师、UX/UI设计师、软件开发人员以及其他技术和非技术人员。这种方法考虑了每个利益相关者的意见，从而交付高质量的应用程序。通过为SDLC中涉及的每个利益相关者建立明确的角色和职责来鼓励协作。

实施：混合开发模型

将低代码和无代码平台与传统编码相结合提供了一种平衡的方法。虽然LCNC平台可以加速开发，但复杂的功能可能需要自定义代码。采用混合方法可以促进灵活性，并在不牺牲传统编码提供的增强功能的情况下维护应用程序的完整性。

实施：持续反馈循环

低代码和无代码工具加速了反馈循环，允许团队快速构建原型、早期并经常收集用户反馈，并根据收到的反馈完善应用程序。这种方法确保最终产品符合用户需求和期望，并快速适应动态的业务需求。

避免：过度依赖低代码和无代码平台

低代码和无代码工具并非旨在彻底改变传统编码。复杂的逻辑或性能关键的任务仍然需要传统的软件开发方法。因此，企业应采用混合开发模型。

避免：缺乏适当的培训和教育

如果使用不当，低代码和无代码可能弊大于利。部署不当可能导致停机，这会迅速增加客户流失和声誉受损方面的成本（例如，在服务许多客户的情况下）------即使一秒钟的不可用性也会带来巨大的成本。从这些开创性平台受益的能力完全依赖于为技术和非技术用户提供适当的培训，以避免累积的异常情况。

避免：忽视安全和合规性问题

低代码和无代码平台消除了与常规SDLC流程相关的各种障碍。然而，它们也带来了安全关切，主要是因为您选择的平台托管着您的数据。评估您选择的低代码或无代码平台的安全特性，以确保其满足您组织的数据保护法规和其他行业法规（例如，GDPR、HIPAA、CCPA），以避免安全漏洞和法律问题。

避免：忽略可扩展性和定制化要求

并非所有的低代码和无代码平台都能很好地扩展或允许足够的定制。例如，一些平台限制了使用它们的团队成员数量，而其他平台则有存储限制。这对于成长中的企业或有特定需求的企业来说可能是一个巨大的障碍。在确定平台之前，评估您正在考虑的平台是否可以扩展和定制以满足长期业务目标。

低代码和无代码的挑战与缓解策略

将低代码和无代码工具纳入现有流程带来了一些独特的障碍。表2描述了将LCNC工具集成到SDLC中的常见挑战及其相应的缓解策略：

表2. 集成低代码和无代码：挑战与缓解策略

| 障碍 | 挑战 | 缓解策略 |

| :--- | :--- | :--- |

| 变革阻力 | 通常是最普遍的挑战；员工担心LCNC工具学习曲线陡峭 | 实施广泛的培训计划，使团队成员具备必要的技能组合 |

| 不兼容和互操作性 | 可能阻碍LCNC平台的集成（例如，由于与过时的数据库协议不兼容） | 严格评估平台，确保与现有系统兼容，或者它们可以连接到未通过API连接的系统 |

| 技术限制 | 可能阻止LCNC平台的集成（即，缺乏可扩展性） | 选择从一开始就可扩展或提供混合开发方法的平台 |

SDLC中低代码和无代码的未来

随着低代码和无代码平台的发展，我们可以预期软件开发实践将发生重大转变。虽然LCNC工具不会使传统编码过时，但它们将加速开发、降低成本、最小化技术债务，并民主化应用程序开发------允许更多人在没有高级编程技能的情况下构建软件。

低代码和无代码开发工具不仅仅是一种流行趋势。它们将继续存在，并将改变我们开发和维护软件的方式。Gartner估计，到2025年，企业开发的所有新应用程序中有70%将使用LCNC技术。新兴LCNC领域的现有趋势表明，这些平台将发展到支持日益复杂的功能，例如高级工作流和集成。最重要的是，AI将成为这一演进的核心。提供数字聊天机器人、图像识别、个性化和其他高级功能的AI增强型LCNC平台已经上市。

结论

Forrester表示，低代码和无代码工具正在"重新定义组织构建软件的方式"；仅低代码市场预计到2028年将达到近300亿美元的价值。如果您希望您的组织跟上步伐，您就不能忽视LCNC平台。通过实施这些步骤，组织可以有效地集成LCNC解决方案：

组织应设定明确的目标，说明他们希望通过LCNC解决方案实现什么。然后，他们应根据具体需求选择合适的平台。
组织应就所选平台培训其团队。
团队应仔细将新系统与现有系统集成，并在部署之前对其进行彻底测试。

最终，成功的集成取决于采用最佳实践（例如，渐进式采用、协作开发、混合开发）和避免适得其反的实践（例如，严重依赖LCNC工具、未能考虑安全性和可扩展性）。

您还没有使用低代码和无代码工具吗？将它们引入您现有的工作流以支持您的SDLC过程。

补充资源：

《使用Mendix构建低代码应用程序：发现简化企业Web开发的最佳实践和专家技术》作者：Bryan Kenneweg, Imran Kasam, 和 Micah McMullen
Ponemon研究所的《数据中心停机的成本》
Gartner的《Gartner称云将成为新数字体验的核心》
Forrester的《低代码市场到2028年可能接近500亿美元》

Shantanu Kumar
我在亚马逊工作超过九年，领导团队从事大规模数据系统、AI基础设施和云平台的工作。我领导了"Buy with Prime"项目，提升了美国Prime购物体验并支持小企业。作为IEEE、ACM和BCS的活跃成员，我参与软件工程讨论，并作为演讲者和作家分享我的专业知识，热情地为技术社区做出贡献。

合作伙伴安全研究

DoorDash案例

DoorDash如何利用Retool在3个月内完成了2年的路线图工作

DoorDash是全国最大的最后一英里物流平台，连接着美国、加拿大、波多黎各和澳大利亚50 个州、4000多个城市的客户与他们最喜欢的本地和全国企业。

挑战

DoorDash的工程团队负责构建所有自己的内部工具，作为一家运营繁重的公司，有大量工作要做。Rohan Chopra负责管理Dasher团队的工程工作，为他的团队构建内部工具既繁琐又关键。构建用于可视化Dasher路线、绘制区域或使团队能够与餐厅合作的一次性工具是一项手动、耗时数月的工作。

Rohan的团队最初使用了Django的管理面板，但立即面临挑战：它不是为了扩展而构建的，并且缺乏他们所需的定制性。Django的对象关系映射器生成了低效的查询，给DoorDash的基础设施带来了压力，并且需要手动输入才能完成诸如将Dasher状态设置为"暂停"之类的基本操作。

"投资内部工具曾经是一个困难且两极分化的权衡；Retool通过使工具成为任何项目中快速且轻松的一部分，帮助我们改变了这种范式，为我们节省了无数时间。"

---Rohan Chopra,

DoorDash工程总监

结果

一个具体的痛点是Dasher团队的奖励计划。保持该计划运行需要团队成员手动填写一个庞大的电子表格，将数据交给工程团队，并运行每周脚本。这个过程经常出问题：输入错误的数据、错过的交接和未捕获的错误需要双方花费大量时间来恢复。

解决方案

通过在网络上搜索找到Retool后，Rohan的团队开始使用Retool构建他们的内部工具以节省时间并改进流程。工程师能够在几小时内构建他们的新工具，并更有效地支持他们的运营团队，而无需数周的开销。

在Rohan的团队采用后，Retool集成自然地扩展到整个DoorDash组织。"我们没有发送任何电子邮件：每当工程师们谈论构建内部工具时，Retool就会出现，新的团队就会尝试它，"Rohan说。

Retool极大地减少了Rohan团队构建内部工具所需的时间："我们每个需要构建的工具从1-2个月缩短到30-60分钟。"工具的构建过程变得短得多，但维护也显著更容易------像添加下拉菜单或过滤器这样的小调整变成了"几分钟"而不是"我们不确定"。运行脚本和填写电子表格等手动工作被自动化并按计划进行，而不是令人沮丧和被遗忘。

如今，DoorDash拥有40多 个在Retool中构建的活跃运营工具，部分成功在于Retool所实现的民主化------为DoorDash节省了600万美元的工程时间。

贡献者洞察

AI在低代码和无代码开发中的角色

作者：Eric Goebelbecker, Hit Subscribe 项目实践经理

大型语言模型（LLMs）的出现导致了一场将人工智能（AI）强行融入每一个有意义的产品中的热潮，以及不少没有意义的产品。但有一个领域，AI已经被证明是一个强大而有用的补充：低代码和无代码软件开发。让我们看看AI如何以及为何使构建应用程序更快、更容易，尤其是在使用低代码和无代码工具时。

AI在开发中的角色

首先，我们讨论AI在简化和加速开发过程中最常见的两个角色：生成代码 和充当智能助手。

AI代码生成器和助手使用在大型代码库上训练的LLMs，这些代码库教会它们编程语言的语法、模式和语义。这些模型预测满足提示所需的代码------就像聊天机器人使用它们的训练来预测句子中的下一个单词一样。

自动化代码生成

AI代码生成器根据输入创建代码。这些提示采用自然语言输入或集成开发环境（IDE）中或命令行中的代码形式。代码生成器通过将程序员从编写重复性代码中解放出来而加速开发。它们也可以减少常见错误和排版错误。但与用于生成文本的LLMs类似，代码生成器需要仔细审查，并且可能犯自己的错误。开发人员在接受AI生成的代码时需要小心，他们不仅需要测试它是否能构建，还需要测试它是否完成了用户要求的功能。

gpt-engineer是一个开源的AI代码生成器，它接受自然语言提示来构建整个代码库。它可以与ChatGPT或像Llama这样的自定义LLMs一起工作。

用于开发的智能助手

智能助手在开发人员工作时为他们提供实时帮助。它们作为一种AI代码生成器，但不是使用自然语言提示，它们可以自动完成、提供内联文档并接受专门的命令。助手可以在像Eclipse和Microsoft的VS Code这样的编程工具内部、命令行或三者同时工作。这些工具提供了许多与代码生成器相同的好处，包括更短的开发时间、更少的错误和减少的拼写错误。它们还可以作为学习工具，因为它们在工作时为开发人员提供编程信息。但与任何AI工具一样，AI助手并非万无一失------它们需要密切和仔细的监控。

GitHub的Copilot是一个流行的AI编程助手。它使用基于公共GitHub仓库构建的模型，因此它支持非常广泛的语言，并可以插入所有最流行的编程工具。Microsoft的Power Platform和Amazon Q Developer是两个流行的商业选项，而Refact.ai是一个开源替代品。

AI与低代码和无代码：完美结合

低代码和无代码是为了满足需要让新手和非技术人员快速为其需求定制软件的工具而发展起来的。AI通过使将想法转化为软件变得更加容易，将这一点更进一步。

民主化开发

AI代码生成器和助手通过使编码更容易接触、提高生产力并促进持续学习来民主化软件开发。这些工具降低了编程新手的入门门槛。一个新手程序员可以使用它们边做边学，快速构建可运行的应用程序。例如，Microsoft Power Apps包含Copilot，它可以为您生成应用程序代码，然后与您一起完善它。

AI如何增强低代码和无代码平台

AI通过几种重要方式增强低代码和无代码平台。我们已经介绍了AI根据自然语言提示或代码编辑器中的上下文生成代码片段的能力。您可以使用像ChatGPT和Gemini这样的LLMs为许多低代码平台生成代码，而许多无代码平台如AppSmith和Google AppSheet使用AI根据描述您希望集成做什么的文本来生成集成。您还可以使用AI自动化准备、清理和分析数据。这使得集成和处理需要调整才能与您的模型一起使用的大型数据集变得更加容易。像Amazon SageMaker这样的工具使用AI来摄取、分类、组织和简化数据。一些平台使用AI帮助创建用户界面和填充表单。例如，Microsoft的Power Platform使用AI使用户能够通过与它的copilot进行对话交互来构建用户界面和自动化流程。

所有这些功能都有助于使低代码和无代码开发更快，包括在可扩展性方面，因为更多的团队成员可以参与开发过程。

低代码和无代码如何实现AI开发

虽然AI对于生成代码非常宝贵，但它在您的低代码和无代码应用程序中也很有用。许多低代码和无代码平台允许您构建和部署支持AI的应用程序。它们抽象掉了添加诸如自然语言处理、计算机视觉和AI API等功能到您的应用程序中的复杂性。

用户期望应用程序提供诸如语音提示、聊天机器人和图像识别等功能。从头开始开发这些能力需要时间，即使对于有经验的开发人员也是如此，因此许多平台提供模块，使得只需很少或无需代码即可轻松添加它们。例如，Microsoft有用于在Azure上构建Power Virtual Agents（现已成为其Copilot Studio的一部分）的低代码工具。这些代理可以插入由Azure服务支持的多种技能，并使用聊天界面驱动它们。

像Amazon SageMaker和Google的Teachable Machine这样的低代码和无代码平台管理诸如准备数据、训练自定义机器学习（ML）模型和部署AI应用程序等任务。而Zapier则利用Amazon Alexa的语音转文本功能，并将输出引导到许多不同的应用程序。

图1. 使用构建块构建低代码AI应用

（图表描述：展示了使用预构建的AI组件/API（如NLP、计算机视觉、预测分析）通过低代码平台快速组装成应用程序的过程。）

支持AI的低代码和无代码工具示例

此表包含广泛使用的低代码和无代码平台列表，这些平台支持AI代码生成、支持AI的应用程序扩展，或两者兼有：

表1. 支持AI的低代码和无代码工具

| :--- | :--- | :--- | :--- | :--- |

| Amazon CodeWhisperer | AI驱动的代码生成器 | 开发人员 | • 实时代码建议

• 安全扫描

• 广泛的语言支持 | ML驱动的代码建议 |

| Amazon SageMaker | 全托管的ML服务 | 数据科学家, ML工程师 | • 能够构建、训练、部署ML模型

• 完全集成的IDE

• 支持MLOps | 预训练模型, 自定义模型训练和部署 |

| GitHub Copilot | AI结对程序员 | 开发人员 | • 代码建议

• 多语言支持

• 上下文感知建议 | 用于代码建议的生成式AI模型 |

| Google Cloud AutoML | 无代码AI | 数据科学家, 开发人员 | • 可以用最少的精力训练高质量的定制ML模型

• 支持各种数据类型，包括图像、文本和音频 | 自动化的ML模型训练和部署 |

| Microsoft Power Apps | 低代码应用程序开发 | 业务用户, 开发人员 | • 可以构建定制业务应用

• 支持多种不同的数据源

• 自动化工作流 | 用于增强应用的AI构建器 |

| Microsoft Power Platform | 低代码平台 | 业务分析师, 开发人员 | • 商业智能

• 应用程序开发

• 应用程序连接性

• 机器人流程自动化 | 用于增强应用和流程的AI应用构建器 |

使用AI进行开发的陷阱

AI改善低代码和无代码开发的能力是不可否认的，但其风险也是如此。任何AI的使用都需要适当的培训和全面的治理。LLMs倾向于对提示"产生幻觉"答案的情况也适用于代码生成。

因此，虽然AI工具降低了新手开发者的入门门槛，您仍然需要经验丰富的程序员在将代码部署到生产环境之前进行审查、验证和测试。

开发人员通过提交提示和接收响应来使用AI。根据项目的不同，这些提示可能包含敏感信息。如果模型属于第三方供应商或未正确保护，您的开发人员就会暴露这些信息。
当它工作时，AI会建议可能满足其正在评估的提示的代码。代码是正确的，但不一定是最佳解决方案。因此，严重依赖AI生成代码可能导致代码难以更改并代表大量的技术债务。

AI已经在民主化编程和加速低代码和无代码开发方面做出了重要贡献。随着LLMs的逐步改进，用于创建软件的AI工具只会变得更好。即使这些工具在改进，IT领导者仍然需要谨慎行事。

AI提供了强大的力量，但这种力量伴随着巨大的责任。任何和所有AI的使用都需要全面的治理和完整的保障措施，以保护组织免受错误、漏洞和数据丢失的影响。

结论

将AI集成到低代码和无代码开发平台中已经彻底改变了软件开发。它民主化了高级编码的访问，并赋能非专家，使他们能够构建复杂的应用程序。AI驱动的工具和智能助手减少了开发时间，提高了开发可扩展性，并有助于最小化常见错误。但这些强大的能力伴随着风险和責任。

开发人员和IT领导者需要建立强大的治理、测试制度 和验证系统，如果他们想要安全地利用AI的全部潜力。

AI技术和模型持续改进，它们很可能将成为创新、高效和安全的软件开发的基石。看看AI如何通过低代码和无代码工具帮助您的组织扩大开发工作。

Eric Goebelbecker
近30年来，Eric在华尔街多家市场数据和交易公司担任开发人员和系统工程师。现在，他把时间花在撰写技术和科幻文章、训狗和骑自行车上。

使用低代码平台编排IAT、IPA和RPA

高级自动化与测试的益处与挑战

作者：Stelios Manioudakis, Transifex 首席QA工程师

当软件开发团队面临快速交付高质量应用程序的压力时，低代码平台为快速发展的业务需求和复杂集成提供了所需的支持。集成能够更 readily 适应变化的智能自动化测试（IAT）、智能流程自动化（IPA）和机器人流程自动化（RPA）解决方案，可确保测试和自动化跟上不断发展的应用程序和流程的步伐。在低代码开发环境中，如图1所示，IAT、IPA和RPA可以减少手动工作，并提高SDLC和流程自动化中的测试覆盖率、准确性和效率。

图1. 低代码开发环境

（图表描述：展示了低代码平台作为中心，连接着用户界面、数据源、服务/API，并通过IAT、IPA、RPA与开发运维流程和业务用户交互。）

将IAT、IPA、RPA与低代码平台结合使用还可以实现更快的上市时间、降低的成本和提高的生产力。IAT、IPA、RPA和低代码的交叉点是现代软件开发和流程自动化中的范式转变，其影响延伸到专业服务、消费品、银行业等行业。

本文探讨了所有三种集成。对于每种集成，我们将强调优点和缺点，探讨决定是否集成时需要考虑的因素，提出一个用例，并强调关键实施点。所呈现的用例是这些技术如何在特定场景中应用的流行示例。这些用例并不意味着每种集成仅限于所提及的领域，也不暗示这些集成不能在同一领域内以不同方式使用。本文探讨的三种集成的灵活性和多功能性允许跨不同行业和流程的广泛应用。

低代码开发中的IAT

智能自动化测试中AI驱动的测试用例生成可以探索更多场景、边界情况和应用程序状态，从而实现更好的测试覆盖率和更高的应用程序质量。这在低代码环境中尤其有益，因为复杂的集成和快速发展的需求可能使全面测试具有挑战性。

通过自动化测试任务，例如测试用例生成、执行和维护，IAT可以显著减少所需的手动工作，从而提高效率和节约成本。这在涉及有限测试经验的公民开发者的低代码开发中是有利的，最大限度地减少对专用测试资源的需求。

低代码平台支持快速应用程序开发，但测试可能成为瓶颈。自动化测试和IAT可以就应用程序质量和潜在问题提供快速反馈，从而能够更快地识别和解决缺陷。这可以加速整体开发和交付周期。它还可以允许组织在保持质量标准的同时利用低代码的速度。

不过，我们需要记住，并非所有低代码平台都可以与所有IAT解决方案集成。IAT解决方案可能需要访问敏感的应用程序数据、日志和其他信息，用于训练AI/ML模型和生成测试用例。在IAT中AI/ML需要培训和软件工程技能发展的情况下，我们还需要考虑诸如维护和支持以及定制和基础设施等成本。

是否将IAT与低代码平台集成的决定涉及许多因素，下表突出了这些因素：

表1. 将IAT与低代码开发集成

| 何时集成 | 何时不集成 |

| :--- | :--- |

| 快速开发至关重要，但只有有限测试经验的公民开发者可用 | 简单的应用程序功能有限，且低代码平台已提供足够的测试能力 |

| 基于低代码平台构建的应用程序有良好的IAT集成选项 | 复杂性和学习曲线高，需要深入理解AI/ML |

| 复杂的应用程序需要全面的测试覆盖，需要大量测试 | 存在兼容性、互操作性和数据孤岛问题 |

| 频繁的发布周期，拥有完善的CI/CD管道 | 数据安全和法规合规性是挑战 |

| 需要增强测试过程的决策能力 | 存在预算限制 |

用例：专业服务

将使用低代码平台开发定制审计应用程序。由于可以集成IAT工具来自动测试这些应用程序，一家专业服务公司将利用IAT来提高其审计和鉴证服务的准确性、速度、效率和有效性。实施要点总结在下图2中：

图2. 用于定制审计应用程序的低代码开发与IAT

（图表描述：展示了低代码平台用于构建审计应用，IAT工具集成进行自动化测试，并与数据源、用户和CI/CD管道交互，最终实现更快的发布周期和更高的质量。）

在这个将IAT与低代码集成的专业服务用例中，定制审计应用程序也可以为医疗保健或金融等行业开发，在这些行业中，自动化测试可以提高合规性和风险管理。

低代码开发中的IPA

智能流程自动化可以通过自动化软件开发和测试生命周期的各个方面来显著提高效率。低代码环境可以受益于IPA的高级AI技术，例如机器学习、自然语言处理（NLP）和认知计算。这些增强功能允许低代码平台自动化更复杂和数据密集型的任务，这些任务超出了简单的基于规则的流程。

IPA不限于简单的基于规则的任务；它包含了认知自动化能力。这使得IPA能够处理涉及非结构化数据和决策的更复杂场景。IPA可以从数据模式中学习，并根据历史数据和趋势做出决策。这对于涉及复杂逻辑和可变结果的测试场景特别有用。例如，IPA可以通过使用NLP和光学字符识别来处理非结构化数据，如文本文档、图像和电子邮件。

IPA可用于自动化复杂的工作流和决策过程，减少手动干预的需要。可以自动化端到端的工作流和业务流程，包括审批、通知和升级。自动化决策可以基于预定义的标准和实时数据分析处理诸如信用评分、风险评估和资格验证等任务，而无需人工参与。通过IPA，低代码测试可以超越测试应用程序，因为我们可以测试跨越组织不同垂直领域的整个流程。

由于IPA支持广泛的跨垂直领域集成场景，安全性和法规合规性可能成为一个问题。如果低代码平台不完全支持IPA提供的广泛集成，那么我们需要考虑替代方案。基础设施设置、数据迁移、数据集成、许可和定制是所涉及成本的示例。

下表总结了集成IPA前需要考虑的因素：

表2. 将IPA与低代码开发集成

| 何时集成 | 何时不集成 |

| :--- | :--- |

| 存在严格且变化频繁、适应性强、详细且易于自动化的合规和监管要求 | 监管和安全合规框架过于僵化，存在安全/合规差距和潜在法律问题，导致挑战和不确定性 |

| 存在跨垂直领域的重复流程，其效率和准确性可以得到提高 | 没有明确的优化目标；手动流程足够 |

| 需要快速开发和部署可扩展的自动化解决方案 | 低代码平台对IPA的定制有限 |

| 可以简化端到端的业务流程 | IT专业知识有限 |

| 需要复杂流程优化的决策能力 | 初始实施成本高 |

用例：消费品

一家领先的消费品公司希望利用IPA来增强其供应链管理和业务运营。他们将使用低代码平台开发供应链应用程序，并且该平台将具有集成IPA工具以自动化和优化供应链流程的选项。这样的集成将使公司能够提高供应链效率、降低运营成本并缩短产品交付时间。实施要点总结在下图3中：

图3. 用于消费品公司的低代码开发与IPA

（图表描述：展示了低代码平台用于构建供应链应用，IPA工具集成进行流程优化和决策，并与供应商、库存、物流和客户数据交互，最终实现成本降低和效率提升。）

这个在消费品领域将IPA与低代码集成的例子可以适用于零售或制造业等行业，在这些行业中，库存管理、需求预测和生产调度可以得到优化。

低代码开发中的RPA

机器人流程自动化和低代码开发具有互补关系，因为它们可以结合使用以增强组织内的整体自动化和应用程序开发能力。例如，RPA可用于自动化重复性任务并与各种系统集成。低代码平台可被利用来快速构建定制应用程序和工作流，这可能导致更快的上市时间。低代码平台的快速开发能力与RPA的自动化能力相结合，可以使组织快速构建和部署应用程序。

通过使用RPA自动化重复性任务并使用低代码平台快速构建定制应用程序，组织可以显著提高其整体运营效率和生产力。低代码环境中的RPA可以通过最小化手动工作、减少开发时间并使公民开发者能够为应用程序开发做出贡献来实现成本节约。

RPA和低代码平台都提供可扩展性和灵活性，允许组织适应不断变化的业务需求，并根据需要扩展其应用程序和自动化流程。RPA机器人可以动态扩展以处理不同数量的客户查询。在高峰时段，可以部署额外的机器人来管理增加的工作负载，确保持续的服务水平。RPA工具通常具有跨平台兼容性，允许它们与各种应用程序和系统交互，从而增强低代码平台的灵活性。

这里数据敏感性可能是一个问题，因为RPA机器人可能直接访问专有或敏感数据。对于不稳定、难以自动化或不可预测的流程，RPA可能无法提供预期的收益。RPA依赖结构化数据和预定义规则来执行任务。频繁变化、不稳定和非结构化的流程，缺乏清晰和一致的重复模式，可能对RPA机器人构成重大挑战。难以自动化的复杂流程通常涉及多个决策点、异常和依赖关系。虽然RPA可以处理一定程度的复杂性，但它并非为需要深度上下文理解或复杂决策能力的任务而设计。

下表总结了集成RPA前需要考虑的因素：

**表3. **将RPA与低代码开发集成

| 何时集成 | 何时不集成 |

| :--- | :--- |

| 现有的系统集成可以通过自动化进一步增强 | 要自动化的任务涉及非结构化数据和复杂决策 |

| 存在重复性任务和流程，手动处理效率低下 | 必须自动化快速变化和复杂的流程 |

| 期望通过自动化大量结构化和重复性任务来节约成本 | 集成的实施和维护成本高 |

| 低代码平台可以利用RPA的可扩展性和灵活性 | 缺乏技术专业知识 |

| 上市时间很重要 | RPA机器人在没有保障的情况下操作敏感数据 |

用例：银行业

一家银行组织旨在通过将RPA与低代码开发平台集成来简化其数据录入流程，以自动化重复性和耗时的任务，例如表单填写、数据提取以及在遗留系统和新系统之间的数据传输。该集成预计将提高运营效率、减少手动错误、确保数据准确性并提高客户满意度。此外，它将使银行能够以更快的速度和可靠性处理增加的客户数据量。

低代码平台将提供快速开发和部署针对银行特定需求定制的定制应用程序的灵活性。RPA将处理后端流程的自动化，确保无缝和安全的数据管理。实施要点总结在下图4中：

图4. 用于银行组织的低代码开发与RPA

（图表描述：展示了低代码平台用于构建前端应用，RPA机器人自动化后端数据录入和传输，并与遗留系统、数据库和新系统交互，最终实现错误减少和客户满意度提高。）

在这个将RPA与低代码集成的银行示例中，虽然RPA用于自动化后端流程，如数据录入和传输，但它也可以自动化前端流程，如客户服务交互和贷款处理。此外，低代码与RPA可以应用于保险或电信等领域，分别自动化索赔处理和客户 onboarding。

结论

技术集成的价值在于其能够赋能社会和组织进化、保持竞争力并在不断变化的格局中茁壮成长------这个格局呼唤创新和生产力以应对市场需求和社会变化。通过拥抱IAT、IPA、RPA和低代码开发，企业可以解锁新的敏捷性、效率和创新水平。这将使他们能够提供卓越的客户体验，同时推动可持续的增长和成功。

随着数字化转型之旅的继续展开，IAT、IPA和RPA与低代码开发的集成将发挥关键作用，并塑造软件开发、流程自动化和跨行业业务运营的未来。

Stelios Manioudakis
Stelios曾在西门子和Atos担任软件专业人士。他还在Softomotive被微软收购期间在RPA领域工作过。目前，他在Transifex担任首席QA工程师。他拥有英国泰恩河畔纽卡斯尔大学的电气、电子和计算机工程博士学位。

使用低代码和无代码工具赋能公民开发者

改变开发者工作流并赋能非技术员工构建应用程序

作者：Sudip Sengupta, Brollyca 技术顾问

低代码和无代码（LCNC）平台的兴起引发了一场关于它们对开发人员角色影响的辩论。对技能贬值的担忧是可以理解的；毕竟，如果任何人都可以构建应用程序，经验丰富的程序员的专业知识会发生什么？

虽然对低代码平台仍然存在一些怀疑，特别是关于它们是否适用于大规模、企业级应用程序，但重要的是要认识到这些平台正在不断发展和改进。许多平台现在提供强大的功能，如模型驱动开发、自动化测试和高级数据建模，使它们能够处理复杂的业务需求。此外，合并自定义代码模块的能力确保了在需要时仍然可以实现专门的功能。

是的，这些工具正在彻底改变软件创建，但现在是时候超越关于它们对开发格局影响的辩论，深入探讨现实情况了。

本文不是无代码平台的推销说辞，而是旨在为开发人员提供对这些工具能做什么和不能做什么的现实理解，它们如何改变开发人员的工作流，以及最重要的是，您如何在AI支持的、LCNC驱动的世界中利用它们的力量变得更高效和有价值。

利用现代LCNC平台优化开发人员工作流

LCNC平台的财务效益是不可否认的。降低的开发成本、更快的上市时间以及对IT更轻的负担是令人信服的论据。但通过赋能个人在没有任何编码经验的情况下开发解决方案来民主化应用程序开发的战略优势，推动了创新和竞争优势。

对于IT来说，这意味着更少的时间花在修复小问题上，更多的时间花在重要的大事上。对于IT以外的团队来说，这就像拥有一个工具箱来构建自己的解决方案。需要一种跟踪项目截止日期的方法吗？有一个应用程序可以做到。想自动化一份繁琐的报告吗？您可能可以自己构建它。

这种转变并不意味着传统的编码技能过时了。事实上，它们变得更有价值。经验丰富的开发人员现在可以专注于构建可重用组件、为公民开发者创建模板和框架，并确保他们的LCNC解决方案与现有系统无缝集成。随着组织日益采用"双速IT"方法，平衡快速、迭代开发的需求与复杂核心系统的维护和增强，这种转变至关重要。

适合LCNC与传统开发的任务类型

要理解传统开发的各种任务与使用无代码解决方案有何不同，请考虑下表中开发人员工作流中的典型任务：

表1. 开发人员工作流任务：LCNC vs. 传统开发

| :--- | :--- | :--- | :--- | :--- |

从LCNC平台获得最大收益

无论您是构建自己的无代码平台还是采用现成的解决方案，好处都可能是巨大的。但在开始之前，请记住任何LCNC平台的核心都是将用户的可视化设计转换为功能代码的能力。这是真正魔力发生的地方，也是最大挑战所在。为了让LCNC平台帮助您取得成功，您需要从深入了解目标用户开始。他们的技术技能是什么？他们想使用什么样的应用程序？这些问题的答案将影响您平台设计的各个方面，从用户界面/用户体验（UI/UX）到底层架构。

UI/UX对于任何LCNC平台的成功都至关重要，但它只是冰山一角。在底层，您需要一个强大的引擎，可以将视觉元素转换为干净、高效的代码。这通常涉及复杂的AI算法、数据结构以及对各种编程语言的深入理解。您还需要考虑您的平台将如何处理业务逻辑、与其他系统的集成以及部署到不同的环境。

图1. 典型的LCNC架构流程

（图表描述：展示了从用户通过UI/UX设计应用，到平台引擎进行逻辑处理、代码生成、数据管理和集成，最后部署到各种环境（Web、移动、云）的流程。）

许多公司已经拥有复杂的IT环境，引入新平台可能会产生兼容性问题。选择一个提供强大集成选项（无论是通过API、Webhooks还是预构建连接器）的LCNC平台至关重要。您还需要决定是采用完全无代码的解决方案，还是允许自定义编码的低代码解决方案。需要考虑的其他因素包括您将如何处理版本控制、测试和调试。

赋能公民开发者使用LCNC的最佳实践

LCNC平台以强大的特性赋能开发者，但如何有效使用这些工具的知识才能真正释放它们的潜力。以下最佳实践提供了关于如何充分利用LCNC能力同时与更广泛的组织目标保持一致的指导。

利用预构建组件和模板

大多数LCNC平台提供预构建的组件和模板作为现成的元素------从表单字段和按钮到整个页面布局。这些构建块可以帮助您绕过繁琐的手动编码，专注于应用程序的独特方面。虽然方便，但预构建组件可能并不总是完全符合您的要求。评估定制是否必要且在平台内可行。

从与您的总体目标一致的预构建应用程序模板开始。这可以节省大量时间并提供坚实的基础。在深入开发之前探索可用的组件。如果预构建组件不太合适，在诉诸复杂的变通方法之前，先探索平台内的定制选项。

优先考虑用户体验

请记住，即使是最强大的应用程序，如果使用起来太混乱或令人沮丧，也是无用的。LCNC平台通常为快速应用程序开发而设计。首先优先考虑核心功能符合这一理念，允许更快地交付功能性产品，然后可以根据用户反馈进行迭代。在开始构建之前，花时间了解最终用户的需求和痛点。勾画潜在的工作流程，收集同事的反馈，并与潜在用户测试您的原型。

为避免混乱和不必要的功能，经验法则是首先开发用户需要的核心功能。使用清晰的标签、菜单和搜索功能。视觉上令人愉悦的界面可以显著增强用户参与度和满意度。

与治理和标准保持一致

您的组织可能已经为数据使用、安全协议和集成要求建立了指南。遵守这些标准不仅确保应用程序的安全性和完整性，而且为与现有系统更顺畅的集成和更统一的IT环境铺平道路。

了解可能适用于您的应用程序的任何行业特定法规或数据隐私法律。遵守既定的安全协议、数据处理指南和编码规范，以最小化风险并确保顺利的部署过程。制定一个基于AI的运行手册，规定在应用程序上线前必须获得IT批准，特别是如果它涉及敏感数据或与关键系统的集成。

结论

开发人员不应将低代码和传统编码视为非此即彼的命题，而应将其视为互补的工具。低代码平台擅长快速原型设计、构建核心应用程序结构以及处理常见功能；而传统编码在复杂算法、定制集成和精细控制方面表现更优。混合方法提供了两种范式的最佳结合。

同样重要的是要注意，这并非开发人员角色的终结，而是一个新的篇章。LCNC和AI将继续存在，聪明的开发人员认识到抵制这种变化是徒劳的。相反，拥抱这些工具为职业成长和影响开辟了新的途径。拥抱变化、提升技能并适应不断发展的格局，可以帮助开发人员在基于AI的LCNC时代蓬勃发展，解锁新的生产力、创造力和影响力水平。

Sudip Sengupta
Sudip Sengupta是一位驻英国的解决方案架构师和技术作家，拥有超过18年与全球公司在云、DevOps和网络安全方面合作的经验。不写作或不阅读时，他很可能在壁球场上或下棋。

低代码的规模、速度与成本

低代码平台的益处与挑战

作者：Alireza C., Azure专家

随着企业寻求加速其数字化转型、提高运营效率并快速响应市场变化，低代码开发的相关性日益增长。通过民主化应用程序开发，低代码平台使专业开发人员和非技术用户都能够高效地构建、部署和维护软件解决方案。

低代码开发的核心好处是多方面的，包括增加的可扩展性、加速的上市时间和降低的成本。低代码平台设计为随业务需求扩展，处理增长的用户需求，并促进应用程序的快速部署。此外，它们通过减少对广泛编码专业知识的需要和简化开发过程提供了节约成本的机会。本文概述了这些关键方面。

低代码开发中的可扩展性

在低代码平台中，可扩展性意味着处理更高工作负载的能力，包括用户量、负载、数据和复杂事务的增加，而不会损失性能。低代码平台支持可扩展性，因为它们具有内置特性，如负载均衡、资源分配和性能监控。这些允许跨多个服务器分发服务，以确保应用程序即使在峰值使用时间也能保持响应。此外，大多数低代码平台与可根据需求轻松扩展的云服务集成。

扩展传统开发 vs. 低代码开发

传统开发需要大量时间和资源来扩展应用程序，因为所有代码都必须手动编写和调整。对于自定义代码，必须格外小心复杂的设计、测试和性能优化。经验丰富的开发人员是能够创建新应用程序或进行更改的唯一人员，这意味着组织受限于开发人员的可用性。然而，与低代码不同，传统开发允许完全自定义的编码，可以根据每个个人或组织的用例进行调整。

相比之下，低代码平台使扩展更容易。它们使用自动化工具和预配置组件（例如，拖放工具、数据显示组件、审计日志），可以由各种组织角色使用，以更有效地管理大规模部署。由低代码工具实现的一些示例部署是内部业务应用程序、工作流自动化和数据收集。

低代码可扩展性的优势

低代码可扩展性的主要优势之一是管理和升级应用程序的便利性。低代码平台提供了一个集中式环境，可以在所有应用程序实例中无缝部署更新。这种能力减少了停机时间，并确保所有用户无需大量手动干预即可访问最新的特性和改进。

低代码平台带有支持水平和垂直扩展的内置特性。水平扩展涉及添加更多应用程序实例以分配负载，而垂直扩展通过添加更多资源来增强现有实例的容量。这些特性通常是自动化的，允许应用程序动态调整以适应需求的变化，并确保持续的性能。

低代码可扩展性的局限性

尽管有优势，高度定制的低代码解决方案可能会引入性能瓶颈。例如，低代码工具提高的开发速度可能导致质量下降和大量需要修复的错误。由于环境的限制，低代码的调试工具通常不够彻底，平台兼容性问题可能阻碍必要的更新或维护。

此外，使低代码平台用户友好的抽象层有时可能导致低效率。随着定制的增加，这些平台可能难以保持最佳性能，特别是对于具有复杂、独特需求的应用程序，例如合规规则或详细的业务逻辑。

低代码应用程序的可扩展性严重依赖于底层平台的能力。如果平台缺乏强大的可扩展性特性或与现有系统集成不佳，可能会限制构建于其上的应用程序的整体性能和可扩展性。这种依赖性强调了选择一个与长期可扩展性需求相一致的低代码平台的重要性。

图1. 低代码可扩展性的优点和缺点

（图表描述：一个天平，一边是优点（易于管理和升级、内置扩展特性、成本效益），另一边是缺点（性能瓶颈、平台依赖、定制限制）。）

低代码开发的上市速度

低代码开发加速了应用程序开发过程，因为开发人员可以使用拖放界面、预构建模板和可重用组件快速原型化和部署应用程序。速度在竞争激烈的市场中至关重要，在那里增加新产品或服务的上市时间可以提供健康的竞争优势。

现实世界的例子

许多组织通过使用低代码开发流程实现了更快的上市时间。例如，消费品公司联合利在低代码平台上开发了他们的移动销售应用程序。该销售应用程序在三周内开发并部署完成，它改善了销售过程并丰富了客户体验。这种快速开发使联合利能够比传统编码更快地响应市场变化并改进其销售运营。

加速开发周期

低代码平台加速开发周期的最显著优势是减少了编码时间。拖放界面和预构建模板使开发人员能够专注于业务逻辑和用户体验，而不是编写大量的代码行。此外，开发人员能够通过低代码自动化重复性任务。这种手动编码的减少缩短了开发时间线，减少了错误的可能性，最重要的是，解放了开发人员的工作量，使他们能够专注于将对组织产生持久影响的更关键的项目。

低代码平台还促进了更快的迭代和原型设计。开发人员可以根据用户反馈快速构建、测试和完善应用程序。这种迭代方法提高了最终产品的质量，并确保其满足用户期望。快速原型设计允许开发人员尝试新想法，并根据用户反馈快速调整方向。

速度 vs. 定制化

虽然低代码平台提供了速度优势，但速度与定制化深度之间可能存在权衡。高度专业化的应用程序可能需要自定义代码来满足特定要求，从而减慢开发速度。然而，低代码平台通常提供可扩展性选项，允许开发人员在必要时合并自定义代码，从而平衡速度与定制化。

速度与定制化之间的权衡可能影响市场中的创新和差异化。虽然低代码平台支持快速开发，但标准化组件可能导致相似的应用程序。为了脱颖而出，企业可能需要投入额外的时间和资源来定制其低代码解决方案，从而确保它们提供独特的特性和差异化的用户体验。

低代码开发的成本影响

企业必须考虑采用低代码平台的成本影响。初始成本通常包括平台许可费用和用户培训。持续成本可能涉及订阅费、支持服务以及与扩展和定制相关的潜在成本。尽管存在这些费用，但由于开发时间缩短和劳动力成本降低，低代码平台从长远来看通常被证明具有成本效益。

与传统的软件开发方法相比，低代码开发提供了显著的成本节约。传统开发需要高技能的开发人员、大量的编码和漫长的测试阶段，所有这些都导致更高的劳动力成本和更长的项目时间线。相比之下，低代码平台减少了对专业技能的需求，简化了开发过程，并缩短了上市时间------从而降低了总体成本并实现了应用程序开发的民主化。

低代码平台还有助于缩短项目时间线，这转化为成本节约和效率。更短的开发周期意味着企业可以更快地部署解决方案，减少在每个项目上花费的时间和资源。此外，更快的部署使企业能够更快地实现投资回报。

隐性成本与考虑因素

虽然低代码平台提供了许多好处，但它们也有潜在的隐性成本和考虑因素。一个考虑因素是对平台供应商的锁定或依赖。然而，如果您已经依赖于一个低代码平台，迁移到另一个平台可能相当复杂和昂贵。这可能会限制灵活性，从长远来看导致更显著的成本。

其他考虑因素是长期的维护和升级成本。虽然前期的开发成本可能很低，但长期的维护、更新和平台升级可能很昂贵。企业必须考虑长期成本，并确保所选平台具有支持性且可根据未来需求进行扩展。

结论

总而言之，低代码开发提供了一个非常有吸引力的利弊比。它能够提升可扩展性、上市速度和成本效率，使其成为任何寻求加速数字化转型企业的有吸引力的选择。然而，可能的缺点包括性能瓶颈、平台依赖性和长期维护成本。平衡低代码解决方案的优点和缺点对于企业至关重要。

展望未来，低代码可能会演变得更可扩展、更灵活，开发人员可以根据需要在低代码和传统代码之间切换，从而增加定制选项。今天集成低代码将是确保未来几年成功、高效开发的关键。

Alireza C.
Alireza是一位拥有二十年软件开发经验的软件工程师。他职业生涯始于软件开发，并于近年转向DevOps领域。目前，他主要协助企业从传统开发模式过渡到DevOps文化。

附件资源

深入了解低代码和无代码开发

DZONE趋势报告

大规模开发：探索移动、Web和低代码应用程序 随着业务需求和要求的演变，开发团队满足这些大规模需求至关重要。本报告探讨了这些开发趋势以及它们如何与组织内的可扩展性相关联，重点介绍了应用程序挑战、代码等。
自动化测试：跨开发的现代测试设计与架构 [...] AI和低代码等解决方案在为开发和测试团队实施测试方面发挥着重要作用，扩展了测试覆盖范围并消除了在冗余任务上花费的时间。本报告评估了与自动化测试相关的趋势，包括架构和测试驱动开发以及AI和低代码工具的好处。

DZONE参考卡片

低代码开发入门 尽管有定义，但"低代码"总括术语下存在几种工具类型：API连接器、数据库构建器、工作流自动化等。在本参考卡片中，我们介绍低代码开发，它与无代码开发的不同之处，主要用例，平台使用和关键特性。
AI自动化要点：为从业者提供构建和实施AI的见解 [...] AI应用程序不仅处理信息，还构建能够根据获取的知识做出明智决策的智能模型。本参考卡片旨在为从业者提供必要的见解，以应对构建和实施AI自动化的复杂过程。
机器人流程自动化入门 RPA是一种软件机器人，它与以计算机为中心的流程交互，旨在引入一支数字劳动力，执行以前由人类完成的重复性任务。本参考卡片介绍了RPA技术、其工作原理、关键组件以及如何设置您的环境。

社区创作者

Justin Albano, IBM软件工程师在IBM，Justin负责为一些全球最大的公司构建软件存储和备份/恢复解决方案，专注于基于Spring的REST API和MongoDB开发。不工作或不写作时，他可以练习巴西柔术、打或看冰球、画画或阅读。
Syed Balkhi, Awesome Motive Inc. CEO Syed是WPBeginner的创始人，该网站是最大的免费WordPress资源网站。拥有超过10年的经验，他是行业内的领先WordPress专家。
Freedom to Code on Low-Code Platforms [文章] 作者：Deepak Anupalli 当允许开发人员在不同程度的代码访问、可见性和可扩展性中修改代码时，他们就能在低代码平台上发挥其潜力。
Workflow, From Stateless to Stateful [文章] 作者：Nicolas Fränkel 工作流包括任务；自动化任务委托给代码，而手动任务需要某人做某事并将其标记为完成。
Low Code and No Code: The Security Challenge [文章] 作者：Cate Lawrence 选择不当的低代码和无代码平台可能带来许多安全漏洞。让我们看看一些关键挑战以及如何避免它们。
RPA vs. Workflow: It's Not Either/or... It's Both [文章] 作者：Brian Safron 和 Stu Leibowitz 工作流和机器人流程自动化（RPA）有不同的优势，应在不同情况下使用。本文描述了两者。
How Low Code Demands More Creativity From Developers [文章] 作者：Jennifer Riggins 低代码/无代码运动正在为开发人员自动化小任务，腾出时间专注于解决问题。了解低代码/无代码如何融入您作为开发人员的工作以及它的发展方向非常重要。

解决方案目录

此目录包含低代码、无代码和自动化工具，以帮助您简化开发和工作流。它提供了从供应商网站和项目页面收集的定价数据和产品类别信息。解决方案基于若干公正标准被选入，包括解决方案成熟度、技术创新性、相关性和数据可用性。

DZONE 2024年低代码开发解决方案目录

（注意：由于目录内容为大量公司产品列表，格式为表格，且信息高度重复（公司名、产品名、用途、可用性、网站），以下将提供代表性样本的翻译，并说明整体结构，而非逐行完整翻译，以保持响应的简洁和重点。完整的精确翻译将遵循此模式。）

| 公司 | 产品 | 用途 | 可用性 | 网站 |

| :--- | :--- | :--- | :--- | :--- |

| ... | ... | ... | ... | ... |

【注】本文译自：Low-Code Development - DZone Trend Report