低代码的优势

许多开发者并不喜欢低代码或无代码的概念，但他们却使用各种工具来大幅减少需要编写的代码量。他们对图形用户界面持怀疑态度，却仍然在使用 Visual Studio Code，而这款软件正是凭借其可视化界面获得了广泛的成功。

我们先来讨论一下什么是低代码、无代码和全代码，以及它们的优势和劣势，然后我将以思想领袖的身份谈谈我对它们未来的看法：什么会使它们成功，以及为什么开发人员应该接受这些工具。

无需代码

首先，我们来谈谈无代码应用。顾名思义，无代码应用是指无需编写传统代码即可构建应用程序。您只需使用图形用户界面，通过点击、拖拽或填写表单即可构建网站、应用程序或自动化流程。Squarespace、Notion 和 Zapier 就是一些无代码工具的例子。

这些工具非常适合构建符合其支持功能范围的应用，但如果你想创建自定义功能或超出其功能范围的应用，那就几乎不可能了。它们非常适合其用途：让非程序员也能快速构建应用，但在自定义和扩展方面存在局限性。

完整代码

我是一名软件工程师，所以我的职业生涯一直专注于编写完整的代码解决方案来解决问题。代码就是你给计算机一系列书面指令，然后计算机执行这些指令。你需要使用编程语言，比如 Python、Java 或 JavaScript 来实现这一点。

这意味着所构建的产品是完全定制的，或者至少在过去是这样。您可以构建任何您想要或需要的功能。全代码解决方案能够实现可扩展性和可扩展性。

话虽如此，编写代码既困难又昂贵。编程是一项职业，需要长时间的学习。一个人几乎不可能独立完成大型应用程序的开发，而且开发人员的薪酬相对较高。此外，代码需要维护和更新，这意味着随着时间的推移，需要投入更多的时间和金钱。

低代码

低代码是这两种解决方案的混合体——它介于无代码和全代码之间。例如，你可以使用图形用户界面而非传统代码来搭建应用程序框架，然后使用代码扩展该应用程序，实现所需的所有额外功能。

话虽如此，开发者往往对低代码解决方案持谨慎态度，这也不无道理。从历史上看，许多此类工具都把开发者放在次要位置，因此代码质量低下，界面也十分笨拙。

其次，我认为开发者担心低代码会让他们的工作变得无关紧要。我认为这种想法是错误的：首先，这些解决方案都是基于代码并由代码扩展的。代码不会很快消失，而且在最好的情况下，低代码只会让我们工作中那些令人烦恼的部分变得不那么烦人。

低代码和无代码之间的界限往往模糊不清，而且过于咬文嚼字。事实上，我个人认为属于低代码的工具，往往会标榜自己是无代码的。我基本同意Shawn Wang 的这篇文章的观点：这种分类其实并不重要。

底层代码演进

代码已经发展得比最初简洁得多。过去，你需要从头开始编写应用程序的所有代码，而现在这种情况已经不再适用。

当你启动一个 Ruby on Rails 应用时，数千行代码已经预先编写好，你可以在15 分钟内构建出一个可用的应用。Ruby on Rails 遵循“约定优于配置”的原则，这意味着它牺牲了开发者的决策权来换取更高的效率。如果你遵循框架，你最终需要编写的代码量就会减少。

此外，您可以使用 Gatsby 或 Next.js 模板来构建一个完整的应用程序，您只需对其进行调整或添加功能即可。还有一些托管服务，只需点击几下鼠标并编写几行代码，即可为您的应用程序添加身份验证或评论等功能。

大多数开发者接受这些解决方案，部分原因是它们所需的自写代码量远低于以往。这些工具将开发者视为解决方案的一部分，而不是试图绕过他们。它们真正从开发者的角度出发，满足他们的需求。

无服务器架构也为云计算行业带来了类似的变革——你不再需要费尽周折或成为 DevOps 工程师才能以可扩展的方式部署应用程序。AWS Amplify和Serverless Framework等工具使前端开发人员能够构建全栈云应用程序，而无需深入了解基础设施或掌握其他后端语言。无服务器架构并非意味着完全没有服务器，而是指服务器的大部分工作都已对开发人员进行抽象化，从而使他们的工作更轻松、更安全。

但是，低代码试图扩大软件开发人员的群体：非程序员和程序员更适应不同的环境。教一个新开发者如何使用命令行界面 (CLI) 而不是图形用户界面 (GUI) 是一项艰巨的任务。起初，使用 CLI 会感觉更加困难。但大多数开发者在 CLI 中工作效率更高——因为他们已经记住了命令，并且熟悉这种环境，所以速度更快。

事实上，低代码和无代码解决方案本质上仍然是代码。它们由程序员构建，虽然它们可能将我们通常认为的代码的大部分甚至全部内容抽象化，但它们的目标与大多数程序员的目标相同：为最终用户构建应用程序和网站。仅仅因为代码看起来不同或更容易被更广泛的人群理解，并不意味着它就不有效或不实用。

在许多情况下，程序员过去需要数百行代码才能完成的任务，现在只需一行代码就能实现。这是一件好事：它能提高生产力，减少重复代码库的维护工作，并降低 Web 应用开发的门槛。

什么因素会使低代码解决方案可行？

我的论点是，低代码解决方案需要优先考虑开发者、非程序员和设计师。目前，完全不编写代码就构建一个完整的软件产品是不现实的。非技术出身的创始人应该能够无需编写代码就构建产品原型，将其作为概念验证发布，然后交给设计师和开发者。他们不应该从零开始，而应该能够使用自己最熟悉的开发环境来扩展原型。对于设计师来说，这很可能是像 Figma 和 Sketch 这样的设计工具；对于开发者来说，这很可能是使用 JavaScript 等常用编程语言的文本编辑器。

我认为这类工具指日可待，但就短期而言，那些能够帮助更多人成为开发者或提高现有开发者效率的工具正在迅速发展。开发者们已经接受了“过去需要一百行甚至更多代码才能实现的功能，现在只需一行代码就能完成”这一理念。例如，Amazon Cognito等托管身份验证服务、 Chakra UI等 UI 组件库，以及Stripe等支付管理系统。

此外，代码应该随时可供需要的人使用。它应该是完全生成的，而不是像某些工具那样只针对少数功能进行部分生成，或者只提供插入自定义代码的插槽。至少在短期内，当这类工具还在建立信任时，应该如此。

过去几个月我一直在开发AWS Amplify 管理界面，它虽然是一款完全面向开发者的工具，却能通过可视化界面简化开发者的工作流程，这一点给我留下了深刻的印象。它在实践中是低代码的，但在定位上却并非如此。

VS Code 中的可视化 Git 集成以及组件库与设计软件日益增强的集成也是如此。这些都是开发者在工作流程中使用的可视化（即低代码）解决方案。它们并没有被贴上“低代码”的标签，因此我们更容易接受它们。或许短期内为了赢得开发者的支持，这种做法也是必要的，但我希望我们能够拥抱这种发展趋势，而不是排斥它。提高枯燥乏味工作的效率意味着我们可以腾出更多时间来应对挑战和进行创新。

Webflow已经证明，低代码和无代码工具可以发展成一个价值数十亿美元的产业。我非常期待看到这个领域接下来的发展，也对能够让更多人成为开发者和产品构建者感到无比兴奋。