低代码方法的破碎承诺

低代码方法的破碎承诺

尽管承诺简化和填补 IT 技能差距,但它可能更像是一种错觉,而不是提升团队交付实际价值的能力。

翻译自 Broken Promises of the Low-Code Approach

图片来自 Shutterstock 的 seamind224

这是一个三部曲系列的第一部分。

很容易被低代码和无代码解决方案的热情所席卷(我将简称为低代码),特别是考虑到它们诱人的简单性和用户友好的界面的吸引力。它们被誉为解决 IT 技能差距的答案,使非技术用户能够在无需编写一行代码的情况下创建功能应用。然而,这些工具对于您的团队的实际效果往往更像是一种幻觉,而不是一个能够彻底改变局面的东西,尤其是在不断演变的编程趋势和工具的背景下进行审视时。

低代码的诱人之处

低代码平台具有不可否认的吸引力,尤其适用于渴望释放团队速度和敏捷性、实现快速应用开发的领导者。对广泛编码知识的需求被消除,节省了 IT 资源,并使能够为应用开发做出贡献的能力民主化。对于拥有有限 IT 资源的中小型企业而言,这可能是一个重要优势。

同样具有吸引力的是低代码解决方案的成本效益。通过减少对经验丰富的程序员的依赖,这些平台有可能大幅降低劳动力成本,而这些程序员往往成本更高且更难以留住。此外,许多低代码平台提供内置的可扩展性,使应用能够处理随着用户群体增长而增加的负载。

低代码核心的误解

事实是,许多低代码解决方案在软件开发方面存在根本误解:它们将理解编程语言语法的挑战与设计有效的应用逻辑的挑战混为一谈。编程语言只是工具;它们的语法仅仅是表达解决方案的手段。软件开发的真正核心在于问题解决,即制定算法、数据结构和接口,以高效地满足应用的需求。

通过图形用户界面(GUI)来简化软件开发,低代码解决方案在不必然简化设计强大应用的基本挑战的情况下替代了语法。这种方法可能会引入多个缺点,同时未能减轻软件创作的真正复杂性,最终可能对团队交付真正价值的能力产生负面影响。

低代码解决方案的其他陷阱

低代码解决方案经常在有限的定制性方面挣扎,通常无法满足特定、复杂或独特的业务需求。供应商束缚的风险是另一个重大不利因素,如果定价、功能提供或供应商关闭,用户可能会陷入困境。我曾亲身经历过这些事件,团队的结果相当灾难性。他们面临严重的技能缺口和长时间的低生产力期。

性能和效率问题也是一个问题。通过低代码平台开发的应用可能不如使用传统代码精心设计的应用性能好,特别是对于大型复杂应用而言。

简单的承诺往往导致意想不到的复杂性现实。虽然低代码平台在创建简单应用方面表现出色,但在处理更复杂场景时往往不够出色。当这些工具由缺乏开发复杂系统经验的人使用时,这种挑战通常会加剧。

最近的趋势提供了一种替代方法

考虑到上述挑战,随着几乎适用于各种情况的代码库和框架的不断增多,低代码解决方案的价值进一步削弱。考虑一些框架,如 Next.jsNitric ,或平台如 SupabaseVercel。这些较新的面向开发者的工具通常比低代码等价物更具生产力,而且肯定使最终的应用更具未来可靠性。

这些解决方案采用了一种不同的提高生产力的方法。它们简化了开发人员的工作流程,保持了传统编码中固有的灵活性,而不是替代小众的低代码选择。这使得低代码解决方案经常难以适应的定制性、适应性和复杂性的能够保持开放,同时允许有限的开发团队以更少的代码实现更多的成果。

我管理的团队通常更热衷于使用面向开发者的框架和工具;它们提供更愉快的开发体验,并拥有更广泛的社区支持。这使得开发团队有动力学习和扩展技能,这些技能将为实现他们个人目标以及团队目标提供帮助。

总结

低代码解决方案虽然实现了软件开发的民主化,但也带来了一系列限制和潜在的缺陷。在某些情况下,根本的误解在于将编程语法与软件开发的真正挑战——问题解决和应用设计等同起来。

此外,全面的代码库和开发者友好的框架的出现,挑战了低代码工具的相关性。通过赋予开发者权力并简化其工作流程,同时保持灵活性,这些现代解决方案提供了一种更具未来可靠性的软件开发方法。

我们认为目标应该是更少的代码,而不是低代码,我们关于这个主题的下一篇文章将讨论为什么以及如何使用新工具来实现这一点。

与此同时,可以了解一下我们在开源的 Nitric 框架中通过自动化来减少所需代码的做法。

这两种方法无疑必须共存,根据项目的复杂性和需求提供不同的服务。然而,了解这些微妙之处对于有效地导航软件开发领域并在每种情况下利用适当的工具至关重要。

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注