许多开发者不喜欢低代码或无代码的想法，然而他们使用工具来大幅降低他们需要编写的代码量。他们对图形用户界面犹豫不决，但却生活在Visual Studio Code中，由于它的可视化界面而获得了广泛的成功。
让我们先讨论一下什么是低代码、无代码和全代码，以及它们的优势和劣势，然后我将以思想领袖的身份，给出我对它们未来的看法：什么会使它们成功，以及为什么开发者应该拥抱这些工具。
无代码
首先，无代码。无代码是指你在构建一个应用程序时，正如其名称所暗示的，没有传统的代码。你使用一个图形用户界面，通过点击、拖动或填写表格来建立网站、应用程序或自动化流程。无代码工具的一些例子包括Squarespace、Notion和Zapier。
这些工具对于建立符合它们所支持的功能的东西来说是很好的，但如果你想创建一些自定义的东西或超出它们的界限，那就不太可能了。它们的目的很好：允许非编码人员快速构建，但它们在定制和扩展方面受到限制。
完整的代码
我是一名软件工程师，所以我的职业生涯主要集中在为问题建立完整的代码解决方案。代码是指你给计算机一连串的书面指令，计算机执行这些指令。你使用一种编程语言，如Python、Java或JavaScript来做这件事。
这意味着建立的产品是完全定制的，或者至少在历史上是这样的。你可以建立你想要或需要的任何功能。可扩展性和可扩充性是可以通过全代码解决方案实现的。
也就是说，代码是困难和昂贵的。编程是一个职业，需要很长的时间来学习。一个人很可能无法成为大规模应用的唯一开发者，而且开发者是一个相对高薪的角色。再加上代码需要维护和更新，这意味着随着时间的推移，会有更多的时间和金钱。
低代码
低代码是这两类解决方案的混合体--它介于无代码和全代码之间。因此，也许你使用图形用户界面而不是传统的代码来搭建一个应用程序的脚手架，但随后你可以使用代码来扩展该应用程序，以使你需要的所有额外功能。
也就是说，开发人员往往对低代码解决方案犹豫不决，这是有道理的。从历史上看，许多这样的工具都把开发者放在第二位，所以代码质量很差，界面也很笨拙。
其次，我认为开发者担心低代码会使他们的工作变得无关紧要。我认为这是误导：首先这些解决方案是由代码支持的，并由代码扩展。代码不会很快消失，在最好的情况下，低代码只会使我们工作中的烦人部分不那么烦人。
低代码和无代码之间的界限往往是模糊的和迂腐的。事实上，我个人会将其归类为低代码的工具，并将其称为无代码。我基本上同意Shawn Wang的这篇帖子：分类其实并不重要。
低代码的演变
代码已经进化到了比原来低得多的程度。以前你必须从头开始写一个应用程序的所有代码，现在已经不是这样了。
当你开始一个Ruby on Rails的应用时，成千上万行的代码已经为你预写好了，你可以在15分钟内建立起著名的可使用的东西。Ruby on Rails依赖于 "惯例而非配置"，这基本上意味着用开发者的决策来换取生产率的提高。如果你遵循这个框架，你可以写更少的代码作为回报。
此外，你可以使用Gatsby或Next.js模板来拥有一个完整的应用程序，你只需要调整或添加功能。还有一些管理服务，可以用来在点击几下和几行代码的情况下向你的应用程序添加诸如认证或评论等内容。
大多数开发人员接受这些解决方案，部分原因是自写的代码量比你历史上需要的少得多。这些工具优先考虑将开发者作为解决方案的一部分，而不是试图绕过他们。它们满足了开发人员的需求。
无服务器也为云计算行业做了类似的事情--你不再需要跳过障碍或成为一名DevOps工程师，就能以可扩展的方式部署应用程序。像AWS Amplify和无服务器框架这样的工具使前端开发者能够构建全栈式的云计算应用，而无需了解大量的基础设施或二级后端语言。无服务器实际上并不意味着没有服务器，它只是意味着服务器大部分被抽象出来，使开发者的工作更容易和更安全。
但是，低代码试图扩大谁可以构建软件：非编码人员在不同的环境中比编码人员更舒服。教导一个新的开发者如何使用CLI而不是GUI是一个很大的任务。起初，使用CLI的感觉要困难得多。但是，大多数开发人员觉得在CLI中更有成效 -- 对他们来说更快，因为他们已经记住了命令，而且在这种环境中很舒服。
事实是，在引擎盖下，低代码和无代码解决方案就是代码。它们是由程序员建立的，尽管它们可能允许大部分或所有我们认为是代码的东西被抽象出来，但它们有助于实现大多数程序员的相同目标：为终端用户建立应用程序和网站。仅仅因为代码看起来不同，或者对更多的人来说更容易理解，并不意味着它不那么有效或不那么有用。
在许多情况下，一个程序员过去能用数百行代码做的事，现在只需一行就能做到。这是一件好事：它导致了生产力的提高，减少了对重复代码库的维护，并且降低了在网络上构建的障碍。
怎样才能使低代码的解决方案可行
我的论点是，低代码解决方案需要优先考虑开发者、非开发者和设计师。现在，用无代码构建一个完整的软件产品是不可行的。对于一个非技术性的创始人来说，应该有可能在没有代码的情况下建立产品的原型，把它作为一个概念的证明，然后把它交给设计师和开发人员。他们不应该需要从头开始，他们应该能够使用他们最熟悉的环境来扩展原型。对于设计师来说，这很可能是像Figma和Sketch这样的设计工具，而对于开发者来说，这将是在他们的文本编辑器中使用JavaScript这样的通用编程语言。
我认为这样的工具即将出现，但在短期内，能够使更多的人成为开发者或使现有的开发者更有效率的工具正在迅速增长。过去需要100行或更多的代码，现在能够是一行代码的想法已经被开发者接受。例如，像Amazon Cognito这样的管理认证服务，像Chakra UI这样的UI组件库，或者像Stripe这样的支付管理系统。
此外，这些代码应该随时提供给需要它的人。它应该是完全生成的，而不是像某些工具那样，只为少数功能提供部分生成，或者有插入自定义代码的插槽。至少在短期内，当这些类型的工具正在获得信任的时候。
在过去的几个月里，我一直在研究AWS Amplify的管理UI，尽管它是一个完全面向开发者的工具，但它通过视觉界面简化开发者工作流程的能力给我留下了深刻的印象。它在实践中是低代码的，但在定位上不是。
VS Code中可视化的Git集成和越来越多的组件库与设计软件的集成也是如此。这些都是开发者在我们的工作流程中使用的可视化（即低代码）解决方案。它们没有被打上这样的烙印，所以我们更容易接受它们。也许这也是在短期内赢得开发者的需要，但我反而希望我们能拥抱这种进步而不是回避它。在枯燥的事情上提高生产力意味着有更多的时间来进行挑战和创新。
Webflow已经证明，低代码和无代码工具可以成为一个数十亿美元的产业。我渴望看到这个领域的下一步发展，我对让更多人成为开发者和产品建设者的可能性感到非常兴奋。
