低代码有利于快速开发，但我们还需警惕它潜在的成本和锁定风险。
译自 The Highs and Lows of Low-Code Tools，作者 Tony Graham 是 Sonar 的产品营销经理。他在企业软件开发方面拥有近十年的经验，拥有丰富的背景，横跨报表程序生成器和 .NET 开发人员、信息系统管理员、Google 软件的角色......
随着软件开发对效率、敏捷性和交付速度的要求比以往任何时候都高，企业发现他们需要数字化转型来获得编写代码方面的优势。为了推动转型和取得结果，公司开始关注低代码解决方案，作为一个强大、精简的方法来让开发者完成工作。
尽管低代码工具一度被视为噱头，但在过去五年中，它们经历了令人难以置信的演变。预计到 2026 年，该行业将达到 445 亿美元，75% 的企业应用程序将由这些解决方案开发。
不要误解：低代码不能取代传统的 Clean Code —— 一致、有意图、适应性强和负责任的编码，这是实现业务结果至关重要的高质量软件的关键。但这并不意味着在每种情况下它都是不合适的选择。
那么，在什么情况下低代码效果最好？我们如何最有效地配备我们的开发人员这些解决方案来执行他们的工作，利用优势并通过正确的应用程序来缓解劣势？
低代码的一个主要优势在于它允许开发者以更快的速度利用时间这个在残酷的商业世界中至关重要的资源。使用这些工具，开发者可以在开发和交付过程中实现重大削减：例如，他们可以在不编写一行代码的情况下快速组装应用程序。预构建模板、拖放功能和可重用组件等元素可以帮助这些技术专家利用他们的时间来处理应用程序构建的更复杂方面，从而保持领先地位。
同样的这些元素也使得低代码工具成为公司弥合技能差距、允许那些没有传统编程背景的人来领导项目某些方面的优秀方式。任何开发者都了解需要大量的教育和培训才能获得那种专业知识，但是低代码工具使这个过程对业务专业人员更加可访问。这有助于清理开发人员的工作积压，在扩大能够为项目做出贡献的利益相关者数量的同时，增加应用程序发布周期中的工作量。
这些工具不仅可以提高生产力，还可以创造广泛的协作和机会，使开发人员可以腾出他们有限的时间。低代码可以更快地添加功能，启用更快的更新，并且以更快的速度将想法转化为现实。简单的界面和易于共享的工作可以增加开发人员接收反馈的速度，此外还需要在过程的后期较少的更改，这些更改会推迟项目的完成。
但是低代码不是一劳永逸、包罗万象的解决方案。那么，开发人员在哪些情况下应该避免使用这些工具呢？
这些解决方案的一个主要缺点是，它们无法像更传统的代码那样进行定制。你所看到的就是你所得到的：你的开发人员可以拖放图标来轻松快速地创建非常简单的应用程序，但是更复杂的项目不适合这些工具。在这种项目工作中使用它们只会创建额外的开销，最终给你的开发人员带来不必要的头痛。这些工具无法处理复杂的业务逻辑；通过提高速度，它们降低了应用程序短处的应对能力。
尽管低代码平台中的修改是有限的，但许多这些系统通过标准编程语言(如 Java、C# 和 JavaScript)实现了扩展性。然而，这些扩展是在低代码平台之外使用传统 IDE 构建的。如果代码扩展不遵循 Clean Code 标准，它们可能会向低代码应用程序中引入漏洞、错误和低效。虽然这种可扩展性允许对低代码平台进行一定程度的自定义，但它也带来了额外的挑战，例如添加只有专业开发人员才能解决的复杂性。
代码安全控制也存在局限性。使用低代码时，所有源代码都会在后台自动生成，开发人员无法获取。这些应用程序依赖于平台的安全性，这意味着开发人员必须信任供应商来确保他们正在保护其所有应用程序和数据。
它们也很昂贵。这些工具的月费用可能达到数万美元，这取决于用户数量。与传统代码不同，这些成本在初始使用后不会缩减。如果一家公司过度依赖低代码工具，供应商锁定也会成为一个问题，使该组织受制于人。最后，随着应用程序变得越来越复杂，低代码维护开销会随时间呈指数增长。随着围绕传统编程语言的变通解决方案的增加，这些工具在故障排除和维护方面也具有挑战性。
我们知道，与所有技术一样，随着更广泛的采用和不断增长的业务需求，低代码解决方案的使用和能力只会继续增加。有很多优势使其成为开发人员在努力交付项目时的有价值工具和可靠选择。
然而，有鉴于这些好处，组织应该对成本和供应商锁定如何为其团队制造障碍持现实态度。使用低代码为部门内应用程序或单页 Web 应用程序提供动力等，是企业应该研究的使用案例类型。
随着公司继续扩大其软件开发组合，它们应该考虑低代码作为一种快速生成代码和帮助开发人员处理随着企业越来越依赖软件而继续增长的大量工作量的方式。与此同时，他们应该记住，与生成式 AI 一样，创建高质量、安全、可维护和可靠软件的最佳方法是在遵循 Clean Code 最佳实践的同时使用这些工具，以获得最佳的业务结果。