无代码什么时候有用 ?

本文最初发表于原作者 Linus Lee 个人博客，经作者授权，InfoQ 中文站翻译并分享。

如果无代码想成为“传统”软件的有力竞争者，就需要从早期软件的错误中汲取教训。

要讨论无代码（no-code）的好处，我们首先来讨论题外话，谈谈无代码和有代码（yes-code）之间的根本区别。

抽象性粒度

软件，是的，代码软件，已经存在一段时间了。作为一个行业，我们学到的一件事就是如何编写出能够优雅发展的软件。遗憾的是，我们并不完美，遗留系统仍然在激增，但作为一个技术行业，我们已经学会了如何构建和发展软件系统，以应对跨越数年和数十年的不断变化的需求和制约因素。

当我们第一次用软件解决问题时，我们会针对当天的约束因素写一些代码。我们不一定知道问题将会如何变化。也许明天就会有不同的客户或利益相关者，或者产品也许会扩展为服务于一个相关的、但不同的问题空间。为了适应不断变化的环境，我们需要能够在不重写的情况下改变软件，这就是软件工程的基本内容：如何改变软件系统。改变是游戏的主题。

在改变方面，我们已经变得得心应手了。我们构建了像 Git 这样的工具，以及像持续集成和代码自动格式化这样的模式，使我们更容易改变代码并保持稳定。特别是在开源领域，我们已经学会了如何操纵大型软件团队。我们还学会了使用更好的抽象。抽象是一种概念性的包装，它将代码库的不同部分（例如，数据源和用户界面）隔离开来，这样一部分可以改变，而另一部分则不会改变。总的来说，我们已经开始弄清楚如何使软件系统的 DNA 能够适应不断变化的时间潮流。

不管是好是坏，无代码似乎会拒绝很多这样的学习。我还没有见过任何一家无代码的公司或产品允许源代码控制（我也见过很多无代码公司，但欢迎你证明我错了）。我还没有见过允许在无代码工作流的各层之间自然构造抽象的无代码产品。对于大规模开发来说，无代码软件的准备也是非常不足的：我们的软件系统需要成千上万的工程师——而对于一个有 1000 名工程师的团队来说，在一套数千人的无代码工作流中工作是什么样子的呢？两个字：混乱。

传统软件已经学会了抽象和模式，这些抽象和模式使软件具有弹性，并能够适应变化和扩展。无代码软件既不能适应不断变化的约束因素，也不能适应开发规模。

尽管存在这些限制，但是我仍然认为，无代码在某些方面具有一定的优势，通过在适应性和可扩展方面进行权衡，可以使无代码工具要好得多。那么，既然如此，什么时候无代码才是有用的呢？

1、过渡性、短暂性软件

答案是显而易见的，而且我们在讨论之前就已经有了答案。那就是过渡性软件，一种具有明确生命周期的软件。如果你的软件系统具有一个有限的、预先定义的生命周期和团队，它就无需担心变化的约束因素或团队的发展。现在，它只需关心如何才能很好地解决问题。

很多软件的生命周期都是有限的，可以预见：早期公司的产品原型、作为交互式在线广告一部分的游戏或应用程序、修补产品中特别紧急问题的快速草图或解决方案、为某个活动或会议、招聘周期或季度目标跟踪而开发的应用程序……所有这些都是具有预先定义的、最长生命周期的项目。它们不需要持续、发展或改变：它们只需现在就可以开始工作，并且通过放弃某些代码的软件抽象的适应性，而无代码软件也能从快速原型开发中获益，这是一个加分项。

我认为我们看到了很多有限时间的软件在过渡。在原型中，从无产品到有产品的过渡；从头脑风暴解决方案到尝试各种设计过程的过渡。保质期有限的软件非常适合使用无代码工具。

2、高变更率的代码

对于另一类软件来说，长期的可维护性无关紧要：高变更率的代码。

所谓的高变更率，是指需求几乎每天都在变化，而今天编写的代码很少会在一个月或一个季度之后还存在。如果你今天写的代码不需要持续和发展，因为明天将会有新的东西取代它的位置，那么构建的速度比适应变化的弹性更重要。

在企业中有很多高变更率的代码。比如，营销网站和登陆页面、用于分析的数据管道、电子商务商店、市场营销活动、支付门户——对这类解决方案的需求变化得非常快，以至于代码不断被重写，如果代码需要更多的替换而不是持久，那么无代码工具就是非常合适的。

避免重蹈覆辙

我认为“无代码”是一种误解。它让我们认为无代码软件是一种趋势的开始，一般软件将减少编码，软件工程也将变得更容易。但事实并非如此。软件工程与构建解决方案无关，只与开发有关。但是，随着时间的推移，改变弹性不再是无代码工具的重点，我认为这没关系。

我认为无代码工具反而是另一种趋势的延伸：重新定义工作流。过去，业务流和工作流都是以 Word 文档形式记录的，分散在各个办公室或者共享文件夹里，甚至只是通过口头在公司内部流传下来的内容。如今，我们已经有了工具，可以构建这些工作流，讨论它们，编辑它们，并更具体地分享它们。对于更多可重复的业务流程和快速完成任务来说，这是一个巨大的福音！我认为这才是真正的胜利。我认为这才是无代码工具的真正成功之处：将工作流具体化。

如果无代码想成为“传统”软件的有力竞争者（虽然我认为它不应该尝试），就需要从早期软件的错误中汲取教训。无代码工具需要理解，产品和软件系统需要几十年来不停地面对不断变化的团队和需求，面对淘汰和替换的产品、公司和标准。这需要进行文化上的转变、工具上的转变，以及作为无代码工程师在工具箱中使用的新一类抽象。每当我们尝试为无代码引入更多的工具和抽象时，我认为无代码只是得到了更多的“代码”。也许这会让我们回到我们开始的地方，并发现有代码是件好事。

毕竟，世界是复杂的。当我们针对世界的复杂性构建软件时，这种复杂性需要解决。软件是复杂的，但它所试图理解的世界也是同样的复杂。

这感觉就像我们走出了无代码的发现阶段，进入了一个我们开始理解无代码能解决哪些问题的时代。我认为重要的是，无代码工具构建者应该专注于这些优势，否则就有陷入重蹈软件行业覆辙的风险。

作者介绍：

Linus Lee，韩国人，Dorm Room Fund 合作伙伴，技术狂热爱好者。

原文链接：

https://linus.coffee/note/no-code