无代码什么时候有用？

要谈论无代码有什么好处，我们首先需要离题，说明无代码软件与“有代码”软件的根本不同之处。

软件-是的-编码软件-已经存在了一段时间。作为一个行业，我们学到的一件事是如何编写优雅发展的软件。我们并不完美-可悲的是，遗留系统仍在激增-但作为一个技术行业，我们已经学会了如何针对跨越数年和数十年的不断变化的需求和限制来构建和发展软件系统。

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

我们变得很会找零钱了。我们已经构建了像Git这样的工具，以及像持续集成和代码自动格式化这样的模式，以使更改代码和保持稳定变得更容易。我们已经学习了如何运营大型软件团队，尤其是在开源领域。我们还学会了使用更好的抽象。抽象是概念性的包装器，它将代码库的不同部分(例如，数据源与用户界面)隔离开来，这样一部分可能会改变，而另一部分不会改变。一般来说，我们已经开始弄清楚如何使软件系统的DNA能够适应不断变化的时间浪潮。

不管是好是坏，no-code似乎拒绝了很多这样的学习。我还没有见过任何允许源代码控制的无代码公司或产品(我也见过很多没有代码的公司，但欢迎您来证明我是错的。)。我还没有找到允许在无代码工作流层之间自然构建抽象的无代码产品。对于大规模的开发，无代码软件也准备得非常不足：我们有数以万计的工程师正在开发的软件系统--1000名工程师组成的团队在一组数千个无代码工作流上工作是什么样子的？一片混乱。

传统软件已经了解了抽象和模式，这些抽象和模式使软件具有弹性，能够适应变化和扩展。没有代码的软件还没有准备好改变约束或开发规模。

尽管有这些限制，我认为无代码有一些利基，在适应性和可伸缩性方面进行权衡可以使无代码工具更好。那么，考虑到这一点，什么时候没有代码是有用的呢？

显而易见的答案，也是我在我们谈话之前得到的答案，是过渡性软件，一种有定义生命周期的软件。如果您的软件系统有一个有限的、预先定义的生命周期和团队，那么它就不需要担心约束条件的改变或团队的成长。现在，它只需要担心如何很好地解决一个问题。

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

我认为我们在过渡过程中看到了很多有限时间的软件。在原型中从没有产品过渡到有产品。集思广益解决方案和尝试多种设计过程中的过渡。保质期有限的软件非常适合无代码工具。

对另一类软件来说，长期可维护性关系不大--高流失率的代码。

我所说的高流失率是指需求几乎每天都在变化，今天编写的代码很少在一个月或一个季度后就会存在。如果您今天编写的代码不一定要持续和发展，因为明天会有新的东西取代它，那么重要的是构建的速度，而不是更改的弹性。

企业中有很多高流失率的代码。营销网站和登录页面、用于分析的数据管道、电子商务店面、营销活动、支付门户-对这类解决方案的要求变化得足够快，以至于代码不断地被重写，如果代码需要更换的次数超过了它需要使用的时间，那么无代码工具是非常合适的。

我认为“无代码”这个词用词不当。它让我们认为，无代码软件是一种趋势的开始，在这一趋势中，通用软件将涉及更少的编码，软件工程将变得更容易。事实并非如此。软件工程不是关于构建解决方案，而是关于发展解决方案。但是随时间变化的弹性并不是无代码工具的重点，我认为这是可以的。

我认为无代码工具反而是另一种趋势的延伸：实体化工作流。业务流程和工作流程过去常常被记录在散布在办公室或共享文件夹中的Word文档中，甚至只是通过公司的口头传统传承下来。现在，我们可以使用工具来构建、讨论、编辑和更具体地共享这些工作流。这对于更可重复的业务流程和快速完成工作是一个巨大的好处！我认为这才是无代码工具的真正优势：将工作流具体化。

如果no-code想要成为“传统”软件的有力竞争者--尽管我认为它不应该这样做--no-code需要从早期软件的错误中吸取教训。无代码工具需要理解，产品和软件系统需要在不断变化的团队和需求，以及在淘汰和替换的产品、公司和标准面前存活几十年。这需要文化转变、工具转变，以及作为无代码工程师在我们的工具带中出现新的抽象类别。每当我们试图为无代码引入更多的工具和抽象时，我认为没有代码只是得到了更多的“代码”。也许这会把我们带回到我们开始的地方，发现代码是好的。

毕竟，世界是复杂的。当我们针对世界的复杂性构建软件时，这种复杂性需要去某个地方。软件是复杂的，但仅限于它试图理解的世界。

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