2023年11月27日
第21卷，第5期

Download PDF version of this article PDF

低代码开发效率

“基于代码的技术的‘寒冬’要来了吗？”

João Varajão, António Trigo, Miguel Almeida

在过去的几年里，软件开发领域见证了低代码技术的兴起。这些技术承诺在开发过程和生产力方面都有显著的改进，但研究文献中几乎没有这些改进的证据。这可能会让你质疑，承诺的收益是否只是软件供应商的宣传。

生产力在软件开发技术的背景下，可以定义为软件商品或服务生产中可能实现的效率。生产力通常用衡量产出、投入和时间的指标来表示。《剑桥词典》将生产力定义为“公司或国家制造商品的速度，通常根据生产商品所需的人数和材料量来判断”；同样，《牛津词典》将其定义为“工人、公司或国家生产商品的速度，以及生产的商品数量，与生产它们所需的时间、工作和金钱相比”。

正如你可能预期的那样，生产力是软件开发中的一个关键问题。低代码、超低代码（准无代码）和无代码技术的出现，正是基于对软件开发中更高效率和效能的追求。

生产和销售低代码技术的软件公司的网站上提出的主要论点，主要集中在生产力的提高上

“在我们的强大工具、模板和连接器的单一平台上，在更短的时间内创建您的应用程序。” (OutSystems)¹³
“……与传统开发相比，您应该期望将应用程序构建速度提高 10 倍，将维护成本降低 50%，并获得卓越的功能。” (Appian)¹
“新项目开发速度提高 10 倍，资源减少 1/10。” (Quidgest Genio)¹⁵
“让您更快上线并更快获得成功。” (Mendix)¹⁰
“无需代码即可疯狂快速地构建应用程序。” (TrackVia)²⁰
“生产力比低代码平台高 8 倍。” (Quidgest Genio)¹⁵
“……最大限度地利用您的资源，并显著改善您的业务成果。” (Appian)¹
“在几天而不是几周内轻松构建和集成高质量的应用程序。” (TrackVia)²⁰
“……改变软件的构建方式，以便您可以快速创建和部署关键应用程序，并随着您的业务发展而发展。” (OutSystems)¹³
“通过抽象化和自动化开发过程，更快地创建更好的软件。” (Mendix)¹⁰

总的来说，这似乎好得令人难以置信，对于正在权衡是否采用这项技术进行软件开发的公司来说，重要的是要区分“广告”和“可实现的目标”。

本文旨在通过展示使用基于代码、低代码和超低代码技术进行的实验室实验结果，来研究生产力方面的差异，从而为该主题提供新的见解。低代码技术已清楚地显示出更高的生产力水平，为低代码在短期/中期内主导软件开发主流提供了强有力的论据。本文报告了程序和协议、结果、局限性和未来研究的机会（扩展了 Trigo 等人²¹的结果）。

背景

源代码是程序员在开发应用程序时编写的一组逻辑指令。一旦编写完成，这些指令将被编译/解释并转换为机器代码。Python、Java、JavaScript、PHP、C/C++、C# 等高级编程语言是基于代码的应用程序开发中使用的技术示例。

另一方面，低代码软件开发包括通过使用支持工具来最大限度地减少手动编码量。其目标是以更快的速度和更少的开发团队努力来开发软件，从而加速软件交付。

低代码/无代码软件开发技术的示例包括 IBM Automation Platform、Zoho Creator、Appian、Mendix、OutSystems、AgilePoint、Google AppSheet、Nintex、TrackVia、Quickbase、ServiceNow、Salesforce App Cloud、Microsoft Power Apps、Oracle Visual Builder、Oracle APEX 和 Quidgest Genio 等等。这些技术的显著特点是，它们允许以最少的手工编码创建软件应用程序。^{22, 23}

通常，低代码平台提供了一个图形化环境，方便应用程序开发，这与基于代码的技术不同，后者需要手动编码（即，在低代码技术中，几乎所有内容都是以图形方式开发的，几乎不需要或不需要编程，允许没有编程能力的人创建软件应用程序）。这些技术的一个缺点是许可成本，已知其高于基于代码的技术。¹⁷

方法

在本研究中，在受控环境中进行了实验室实验，遵循预先定义的程序和协议，以实现精确的测量。² 这些实验被设计为客观的，因此结果中不存在偏差（例如，由研究人员的影响/观点造成的结果）。⁹

潜在的研究问题是：低代码技术是否比基于代码的技术产生更高的软件开发生产力（如灰色文献中所报告的那样）？研究的变量是在软件应用程序的创建和维护中的生产力。

对于每个实验，选择了一种软件开发技术（基于代码、低代码或超低代码（准无代码）），并邀请一位在所述技术方面具有成熟技能的开发人员参与。在基于代码的技术的情况下，选择了开发人员首选的技术。生产力计算基于 UCPA（用例点分析）方法。¹²

实验的人工和受控环境使得精确测量执行时间成为可能；这在其他类型的研究中是不可能的，例如现场实验，在现场实验中，控制所有影响任务执行的外部刺激是不可行的。²⁴

实验分为五个阶段

0 实验设计

I 简报

II 软件应用程序开发（创建）

III 软件应用程序开发（维护）

IV 结果分析

阶段 I、II 和 III 针对实验中涉及的每种技术重复进行。

阶段 0 – 实验设计

阶段 0 是要进行的各种实验的准备阶段，仅执行一次。在此阶段，定义了要遵循的程序；创建了指定要开发和维护的应用程序的协议（分为两个阶段）；并指定了用于估计和测量生产力的方法。协议可在 https://doi.org/10.5281/zenodo.6407074 下载。

UCPA 方法是从几种可能的替代方法（例如，代码行、¹⁴ COCOMO II（构造性成本模型）、¹⁹功能点分析⁸ 等）中选择的，因为它侧重于要开发的应用程序的功能，并且独立于要使用的技术（在定义的实验中，这至关重要）。

该方法包括以下阶段：^2,3,11

1. 使用变量 UAW（未调整的参与者权重）和 UUCW（未调整的用例权重）计算 UUCP（未调整的用例点）变量，分别与参与者和用例的感知复杂性相关：UUCP=UAW+UUCW

2. UUCP 调整，考虑技术和环境性质的一组因素，这些因素反映在变量 TCF（技术复杂性因子）和 EF（环境因子）中。变量 UUCP 与变量 TCF 和 EF 的组合产生了项目的可评估 UCP（用例点）：UCP=UUCPxTCFxEF

3. 最后，UCP 变量乘以 PF（生产力因子），它表示开发每个 UCP 所需的小时数：总工作量=UCPxPF

因此，以 UCPA 模型为参考，计算了 PF 变量：结果 PF 越低，研究技术的生产力越高。

实验分为两个主要部分：第一部分（阶段 II）创建了一个软件应用程序；第二部分（阶段 III）包括该应用程序的维护（纠正性和演进性维护）。

附录 A.1、A.2 和 A.3 标识了实验协议中描述的参与者和用例，以及它们各自的分数（权重）。

对于实验的第一部分（软件应用程序的创建），TCF 的值设为 1，考虑到应用程序的低复杂性。鉴于实验的目的是确定每种技术的 EF 值，UCP 变量的起点也设置为 1。因此，对于实验的第一部分（阶段 II）

UUCP=UAW+UUCW=125+9=134

UCP=UUCPx1x1=134x1x1=134

对于实验的第二部分（维护），要求参与者进行两项更改（对应 20 个点的权重）并实施新的用例（也对应 20 个点），如附录 A.3 所示。因此，总共对于实验的第二部分（阶段 III）

UUCP=UAW+UUCW=40+9=49

UCP=UUCPx1x1=49x1x1=49

在整个实验过程中，研究人员始终在场。每当开发人员提出要求时，都会对要开发的应用程序提供额外的说明。还应注意的是，实验被完整地录制在视频中，以供后续分析。休息时间（例如，用餐时间）被记录下来，但不计入生产力计算。在实验期间，开发人员可以访问他们需要的所有信息；唯一的限制是他们不能联系其他开发人员寻求帮助。

阶段 I – 简报

阶段 I 是准备阶段，包括向开发人员介绍协议和进行实验的条件。详细介绍了用例，以及模型和数据模型要求。还定义了自由度——例如，关于图形界面的配色方案。

最终应用程序尽可能接近模型的重要性得到了充分强调，并且严格遵守规范的需求也得到了强调——开发人员被告知要抵制“以任何其他方式会更好”的诱惑——因为计划在实验的最后阶段进行质量评估，以考虑这些方面。时间测量在完成此阶段后开始。

阶段 II – 软件应用程序开发（创建）

阶段 II 的目标是按照实验第一部分中定义的协议创建一个新的应用程序。每个开发人员的活动都被录制在视频中，并且团队的一名研究人员始终在此阶段在场。除了与定义的用例相对应的编程之外，开发人员执行的活动还包括所用开发环境的配置、数据库的创建和测试。应该注意的是，补充活动因所用的开发技术而异。

阶段 III – 软件应用程序开发（维护）

阶段 III 遵循与阶段 II 相同的程序，只是目标不是创建新的应用程序，而是维护（纠正性和演进性维护）现有应用程序（在阶段 II 中创建的应用程序）。此外，这些活动基于新的协议和要求（见附录 A.3），这些协议和要求仅在完成阶段 II 后才提供（即，在阶段 II 中，开发人员不知道阶段 III 的协议）。

阶段 IV – 结果分析

在完成实验后，检查了时间记录（手动记录）和执行活动的视频，以确保时间计数的准确性。此外，为了提高每种技术实现的生产力计算的准确性，在至少两名研究人员的参与下，对每个生成的应用程序进行了质量评估，考虑了四个基本标准：与模型的符合性；用例中描述的功能的实现；错误的发生；以及应用程序性能。请注意，尽管对各种应用程序的质量评估导致最终计算的生产力存在细微差异，但这并未对作为实验一部分的各种技术之间的生产力差异或研究的总体结论产生重大影响。

结果

使用所选技术的最新版本进行了三项实验：基于代码 (Django/Python⁴)；低代码 (OutSystems¹³)；和超低代码 (Quidgest Genio¹⁵)。所有参与的开发人员（每个实验一名）都具有在专业环境中应用目标技术的经验。研究人员联系以访问参与者，这决定了低代码技术的选择。在基于代码的技术的情况下，参与者选择了 Django/Python（他也具有使用其他几种技术的经验，包括 PHP、C# 等）。所有参与者都熟悉实验领域（了解所涉及的概念）和要开发的应用程序类型。

对于每个实验，结果（在表 1 中列出）都基于变量

QF（质量因子）
已实现的 UC（考虑 QF）
时间（小时）
PF（不考虑 QF）
PF（考虑 QF）

此外，对于每个变量，都列出了阶段 II（软件应用程序创建）和阶段 III（软件应用程序维护）的结果，以及整个实验的结果（总计）。

QF 变量与最终产品的质量相关，并考虑了四个基本标准来确定：（1）与模型的符合性；（2）用例中描述的要求的实现；（3）错误的发生；以及（4）应用程序性能。

例如，如果应用程序在特定用例的实现中与相应的模型相比存在细微偏差，而对功能没有任何影响，则与该用例相对应的 QF 变量将受到 5% 的处罚。但是，如果发生错误而妨碍了功能的使用，则处罚可能会高达 100%。

QF 变量的最终值（每种技术）来自应用程序总体质量的加权平均值（考虑用例的权重）。例如，0.9 的 QF 可以解释为应用程序满足相应协议中描述的规范的 90%。两位研究人员审查并应用了创建的测试脚本，以减少质量评估中的偏差。最后，应用程序性能标准未被考虑，因为在生成的应用程序之间未发现差异。如果存在此类差异，则可能是由于 Web 服务器容量而不是所涉及的技术。

因此，已实现的 UC 变量（考虑 QF）对应于有效实现的 UC，并通过将实验的 UUCP 变量乘以 QF 变量来计算。

时间变量对应于应用程序的创建/维护时间，以小时为单位。

PF 变量（不考虑 QF）由计算的生产力因子组成，仅以实验的 UUCP 为参考（即，UUCP/时间）；此变量忽略与协议中规范的符合程度 (QF)。

最后，PF 变量（考虑 QF）由计算的生产力因子组成，以已实现的 UC 变量（考虑 QF）为参考。因此，此变量更好地反映了生产力，因为它考虑了有效实现的 UC（考虑 QF），而不仅仅是实验协议中指定的 UC。

讨论和结论

通过首先分析 QF 变量，可以验证，在基于代码和低代码技术的情况下，从实验的第一部分（阶段 II）到第二部分（阶段 III），应用程序的质量有所下降。超低代码技术的情况并非如此。鉴于实验协议中更改的性质，这不应归因于正在研究的技术，而主要归因于开发人员进行的有限测试。

例如，在阶段 III 中，使用低代码技术维护的应用程序的 PF 在用例实现中受到了惩罚，因为编码错误导致应用程序中止正常运行。然而，总的来说，低代码和超低代码技术在本实验中允许开发更强大的应用程序。但重要的是要强调，无论采用何种技术，在软件开发过程中都不能忽视严格的测试。

考虑到 PF 变量，只有在基于代码的技术的情况下，从阶段 II 到阶段 III 才有所改进。在将其与低代码技术进行比较时，必须将这一方面放在适当的角度来看待，因为在实验的阶段 II 中，基于代码的技术需要大量时间进行设置活动（例如，数据库创建），而在阶段 III 中不必重复这些活动。低代码技术已被证明在设置活动中更有效。因此，总值（表 1 中的“总计”列）更好地反映了实验的实际情况。

表 2 和表 3 列出了在各种实验中验证的生产力比较。表 2 未考虑 QF 变量，而表 3 则列出了考虑 QF 变量的差异。尽管考虑 QF 变量可以使测量更精确，但比较中也包括了不考虑质量的情况，以验证它是否会影响全局结论。结果表明，无论是否考虑 QF，实验的发现保持不变。

总的来说，在这些实验中，低代码技术显示出比基于代码的技术高得多的生产力，生产力提高了约三倍到十倍。

这扩展了先前的工作²¹，并且与一些灰色文献报告一致，这些报告指出，使用低代码技术开发应用程序可以加速该过程，⁵ 从而实现更快的交付和更高的生产力。^6,16 例如，Forrester 的研究表明，低代码平台将开发速度提高了约五到十倍。¹⁸

根据 Gartner⁷ 的说法，到 2025 年，低代码将占软件开发活动的 70% 以上。本文介绍了首批基于研究的研究之一，该研究侧重于不同类型的开发技术之间的生产力差异。

然而，这并非没有局限性。首先，所选技术并不代表“所有”现有的低代码和基于代码的技术。它们包括一些最流行的技术，但可能有更多技术可以成为实验的一部分。

其次，实验的协议指定了“管理软件”应用程序——并且还有许多其他类型，例如多媒体。研究不同技术的“适用性”会很有趣，考虑到要开发的应用程序类型。

第三，开发/维护应用程序软件的协议旨在由单个开发人员在短时间内实施。由于软件开发活动通常是一个协作过程，因此这为进一步研究开辟了空间。

最后，实验的参与者都是经验丰富的开发人员，他们熟悉他们使用的特定技术。他们不同的个人资料可能是偏差的来源。

总的来说，这些局限性可能对记录的时间产生较小的影响，但不会使结论受到质疑，因为低代码技术已清楚地显示出更高的生产力水平。然而，还需要进一步的研究来丰富关于这些技术的生产力的知识库（用于复制研究的完整程序和协议详细信息可在 sites.google.com/view/sdtproductivity 找到。）

正如 Varajão^22,23 所述，“由人工智能等创新技术支持的低代码、超低代码和无代码软件开发预计将迅速加速在全球范围内的采用，成为数字化转型的主要推动者。” 在这些实验中发现的生产力差异清楚地为低代码技术在短期/中期内主导软件开发主流提供了强有力的论据。

致谢

作者要感谢研究参与开发人员。特别感谢 James Maurer 的所有支持（和耐心）。我们还要指出，本研究未获得公共、商业或非营利领域的任何特定资助。

附录

参考文献

1. Appian; https://appian.com.

2. Balijepally, V., Mahapatra, R., Nerur, S., Price, K. H. 2009. Are two heads better than one for software development? The productivity paradox of pair programming. MIS Quarterly 33(1), 91–118; https://dl.acm.org/doi/10.5555/2017410.2017418.

3. Clemmons, R. K. 2006. Project estimation with use case points. Crosstalk, The Journal of Defense Software Engineering 19(2), 18–22; https://www.researchgate.net/publication/200036324_Project_Estimation_With_Use_Case_Points.

4. Django; https://django.ac.cn.

5. Forrester Consulting. 2019. Large enterprises succeeding with low-code.

6. Gartner. 2020. The 2020 Gartner Magic Quadrant for enterprise low-code application platforms.

7. Gartner. 2021. Forecast analysis: low-code development technologies; https://www.gartner.com/en/newsroom/press-releases/2022-12-13-gartner-forecasts-worldwide-low-code-development-technologies-market-to-grow-20-percent-in-2023.

8. Lokan, C. 2005. Function points. Advances in Computers 65, 297-347; https://www.sciencedirect.com/science/article/abs/pii/S0065245805650073.

9. McLeod, S. 2012 (updated 2023). Experimental method. Simply Psychology; https://www.simplypsychology.org/experimental-method.htmll.

10. Mendix; https://mendix.com.

11. Nageswaran, S. 2001. Test effort estimation using use case points. Quality Week; https://www.researchgate.net/publication/228954898_Test_effort_estimation_using_use_case_points.

12. Ochodek, M., Nawrocki, J., Kwarciak, K. 2011. Simplifying effort estimation based on use case points. Information and Software Technology 53(3), 200-213; https://www.sciencedirect.com/science/article/abs/pii/S095058491000176X.

13. OutSystems; https://outsystems.com.

14. Pressman, R., Maxim, B. 2020. Software Engineering: A Practitioner’s Approach, 9th edition, McGraw-Hill Education; https://www.mheducation.com/highered/product/software-engineering-practitioner-s-approach-pressman-maxim/M9781259872976.html.

15. Quidgest Genio; https://genio.quidgest.com.

16. Richardson, C., Rymer, J. 2016. Vendor landscape: the fractured, fertile terrain of low-code application platforms. Forrester Consulting; https://www.forrester.com/report/Vendor-Landscape-The-Fractured-Fertile-Terrain-Of-LowCode-Application-Platforms/RES122549.

17. Sahay, A., Indamutsa, A., Di Ruscio, D., Pierantonio, A. 2020. Supporting the understanding and comparison of low-code development platforms. 46th Euromicro Conference on Software Engineering and Advanced Applications (SEAA), 171–178; https://ieeexplore.ieee.org/abstract/document/9226356.

18. Sanchis, R., García-Perales, Ó., Fraile, F., Poler, R. 2020. Low-code as enabler of digital transformation in manufacturing industry. Applied Sciences 10(1), 1–17; https://www.mdpi.com/2076-3417/10/1/12.

19. Sommerville, I., 2018. Software Engineering, 10th edition. Pearson; https://www.pearson.com/en-us/search.html?aq=software%20engineering.

20. TrackVia; https://trackvia.com.

21. Trigo, A., Varajão, J., Almeida, M. 2022. Low-code versus code-based software development: Which wins the productivity game? IEEE IT Professional 24(5), 61–68; https://www.computer.org/csdl/magazine/it/2022/05/09967415/1IIYACGLXnq.

22. Varajão, J. 2021. Software development in disruptive times. acmqueue 19(1), 94–103; https://queue.org.cn/detail.cfm?id=3458743.

23. Varajão, J. 2021. Software development in disruptive times. Communications of the 64(10), 32–35; https://cacm.acm.org/magazines/2021/10/255713-software-development-in-disruptive-times.

24. Wenz, A. 2021. Do distractions during web survey completion affect data quality? Findings from a laboratory experiment. Social Science Computer Review 39(1), 148-161; https://dl.acm.org/doi/abs/10.1177/0894439319851503.

João Varajão 是葡萄牙米尼奥大学/ALGORITMI 研究中心/LASI 的信息系统和项目管理教授和研究员。他发表了大量同行评审的出版物，并撰写和编辑了书籍、书籍章节和会议交流。他担任会议和国际期刊的主编、副编辑和科学委员会成员。ORCID: 0000-0002-4303-3908。

António Trigo 是葡萄牙科英布拉理工学院管理信息系统教授，也是 ALGORITMI 研究中心/LASI/米尼奥大学的研究员。他发表了同行评审的出版物，并撰写了书籍和会议交流等项目。在加入学术界之前，他曾担任软件工程师和项目经理。ORCID: 0000-0003-0506-4284。

Miguel Almeida 于 2020 年在葡萄牙科英布拉理工学院科英布拉会计与管理学院获得管理信息系统硕士学位。他在德勤葡萄牙担任程序员。此前，他曾在 Softinsa 担任软件开发人员。

最初发表于 Queue vol. 21, no. 5—
在数字图书馆中评论本文

更多相关文章

Catherine Hayes, David Malone - 质疑评估非加密哈希函数的标准
尽管加密和非加密哈希函数无处不在，但它们的设计方式似乎存在差距。加密哈希存在许多由各种安全要求驱动的标准，但在非加密方面，存在一定程度的民间传说，尽管哈希函数历史悠久，但尚未得到充分探索。虽然针对真实世界数据集的均匀分布很有意义，但在面对具有特定模式的数据集时，这可能是一个挑战。

Nicole Forsgren, Eirini Kalliamvakou, Abi Noda, Michaela Greiler, Brian Houck, Margaret-Anne Storey - DevEx 在行动
随着领导者寻求在财政紧缩和人工智能等变革性技术的背景下优化软件交付，DevEx（开发者体验）在许多软件组织中越来越受到关注。直观地看，技术领导者普遍认为，良好的开发者体验可以提高软件交付的效率和开发者的幸福感。然而，在许多组织中，旨在改进 DevEx 的拟议举措和投资难以获得支持，因为业务利益相关者质疑改进的价值主张。

Ivar Jacobson, Alistair Cockburn - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界，其中不断开发新的工具、技术和技巧来服务于商业和社会，但它也很健忘。在其快速前进的过程中，它容易受到时尚潮流的影响，并且可能会忘记或忽略针对其面临的一些永恒问题的成熟解决方案。用例于 1986 年首次引入，并在后来普及，是这些成熟的解决方案之一。

Jorge A. Navas, Ashish Gehani - OCCAM-v2：结合静态和动态分析以实现有效且高效的程序整体特化
OCCAM-v2 利用可扩展的指针分析、值分析和动态分析来创建一个有效且高效的工具，用于特化 LLVM 位代码。实现的程序代码大小缩减程度取决于特定的部署配置。每个要特化的应用程序都附带一个清单，该清单指定先验已知的具体参数，以及运行时将提供的剩余参数的计数。部分求值的最佳情况发生在参数被完全具体指定时。OCCAM-v2 使用指针分析来去虚拟化调用，从而允许它消除任何直接调用都无法访问的函数的整个主体。