多年来，低代码工具和平台使人们能够创建有用的软件系统，而无需编写和维护大型自定义代码库——赢得了几乎同等数量的倡导者和批评者。

有权威机构预测，到 2025 年，将有多达 70% 的新应用程序会使用低代码工具和平台创建。开发人员持续短缺促使企业探索加速软件交付和减少工作量的新方法，越来越多的组织正在探索该技术可以为他们做什么。

近年来，低代码功能已经非常成熟，但怀疑仍然存在——这是有充分理由的。虽然低代码工具有可能为新一代所谓的“公民开发人员”提供支持，并通过简化简单功能的创建来减轻开发团队的压力，但事实仍然是它们并不适合所有开发场景。

确定低代码是否适合您并最终获得它可能为您的业务提供的价值的第一步是了解它最适合支持什么。

何时（和何时不）使用低代码

导致组织采用低代码平台的驱动因素有很多。以下是四种最常见的情况，看看低代码在每种情况下的适用程度：

场景#1：应对开发人员短缺

由于全球对开发人才的需求仍然大大超过供应，使任何用户都能构建强大软件的工具的前景令人信服。但是，由于组织中缺乏开发和编码技能而选择采用低代码可能会导致麻烦。

如果没有熟练的开发人员和 IT 专家监督业务团队使用低代码创建的内容，您将获得“没有策略的软件”：业务线通过定制的单点解决方案不断解决问题，它们之间几乎没有凝聚力或互操作性。这是一个无法扩展的场景，并且与平台思维等领先实践完全不一致。IT领导层需要制定战略并设置护栏，允许在适当的情况下开发低代码解决方案，使业务用户能够解决重要问题，而不会产生大型复杂的问题（技术债务，无法扩展的系统）。

场景#2：支持业务快速增长

对于早期阶段的纵向扩展，低代码有助于快速创建新的功能和服务，而无需过于急剧地扩展开发资源。反过来，这确保了他们的软件不会成为他们组织快速增长的瓶颈。

但是，这些组织需要认识到，他们使用低代码平台创建的许多解决方案最终可能不得不被替换。否则，他们可能会发现其基础架构的核心部分建立在不灵活的基础上。事实上，对于许多使用低代码构建的应用程序来说，这是一个挑战。

为了从低代码中获得最大价值，成长中的企业应该使用它来快速创建所需的功能，但要准备好停用这些功能，并在超出它们时用更强大的功能取而代之。

场景#3：构建新的业务关键型软件

软件对您的业务越重要，低代码就越不可能成为构建和维护它的正确选择。这并不是因为低代码缺乏构建关键应用程序的能力或复杂性，而是因为业务关键型应用程序需要能够轻松扩展、增长和转换。

即使你的应用程序的原始设计处于低代码的最佳位置，如果它对你的业务至关重要，那么设计很有可能在未来需要发展。您可能需要添加更复杂的功能，将它们与其他应用程序集成或将其迁移到新的企业平台。如果业务和 IT 部门之间没有适当地规划，这些事情会困难得多。

场景#4：授权业务线

如果您的目标是为业务线提供更大的技术自主权，并使您的团队成为公民开发人员，那么采用低代码工具是一个很好的方法。低代码对用户来说很容易上手，团队可以快速开始管理和增强功能以满足自己的需求。

但是请记住，即使拥有最直观的工具，IT 也应该参与低代码工具的选择和扩展。并非所有低代码工具都是平等的，选择具有足够可扩展性并且可以集成到更广泛的 IT 生态系统中的工具非常重要。

平衡的重要性

当低代码首次出现时，围绕该技术的大部分叙述将其定位为传统开发的替代方案——它将减少甚至消除组织对熟练开发人员的依赖。

事实证明，这种说法非常无益，无论是从它对低代码设定的不切实际的期望方面，还是从它将低代码和传统开发流程定位为敌人或对立面方面。

问题不应该是“低代码还是传统代码”？它应该是“低代码在哪里可以最好地支持和补充我们的专家开发人员？

通过在正确的用例中启用和鼓励低代码（通常增强业务客户小型团队使用的软件功能），您可以加快交付速度、缩短周期并快速满足业务需求，而无需完全取消当前的开发实践。

您可以保留核心 IT 和开发团队提供的所有控制、治理和战略输入，同时增强业务线的能力并加快交付速度。两全其美是可能的，但前提是您取得了适当的平衡。

低代码不是一刀切的，但它有很多东西可以教给我们。

低代码不能替代代码。如果一个组织要退休其开发团队并使用低代码平台将开发缰绳完全移交给业务团队，那么他们所能实现的目标将非常有限。

百特搭低代码平台架构

但对于一些特定的场景，低代码仍然是一项非常强大的技术。通过将低代码与传统代码和开发实践一起应用，组织可以在不牺牲核心软件所需的灵活性和可扩展性的情况下为公民开发人员提供支持。这是真正的低代码最佳点——解决业务部门具体的个性化和多变的业务需求，由 IT 专家审查，并与传统开发实践和资源一起应用，而不是取代它们。