零代码时代即将到来？没那么简单

立宁 · 发布于 2023-4-20 14:23:35

大数据文摘出品

来源：alexhudson

编译：木槿、徐玲、楚阳、钱天培

“零代码”概念如今变得越来越流行。

“零代码”意味着，无需专业的软件知识，你也能轻松规划一个商业逻辑或者开发一个应用程序。

这当然是一个好的趋势，而且，市场上已经呈现了一些优秀的“零代码”工具。

所以，“零代码”时代真的要到来了嘛？没那么简单！

为什么要“零代码”？

“零代码”的优势很明显。培养一个软件开发人员的本钱很高，人才稀缺，而且一般的软件开发人员资历尚浅，再加上运维本钱很高，软件项目的开发也就困难重重。

一个“数字化企业”需要大量的软件，而且绝大部分都是量身定制的，无法实现量产。于是，整个市场对软件的需求量是非常大的。

假设有一种全新的方式可以取代开发大量软件的过程而同样实现产业数字化，何尝不是一种严重的突破呢？然而，万事开头难。

将整个商业流程数字化有以下两个明显的好处：

然而，许多企业的数字化转型都以失败告终。因为要实现这一质的飞跃，一般企业先得转型成为至少半个软件开发公司，当然，大多数企业并不具备这样的条件。只要拥有足够的资源（时间，资金，人员），开发软件并非一件难事，但人们大都擅长表达各种奇思妙想而缺乏把这些想法落实到位的才干。

“零代码”处置了什么问题？

编写代码不只是数字化转型的关键也是其制约。因为代码通常不是那么好些的，于是，简化代码或者实现“零代码”的意义是宏大的。

简言之，用规范的程序语言语法来编写和实现商业逻辑是一件枯燥乏味的事情。就像会开车的人只需掌握简单易操作的驾驶技巧而无需晓得发动机如何工作一样，代码界也需要这样的运作形式以实现软件开发的普适化。

不幸的是，这个问题已经被认真研究过很长时间了，却没有被很好地处置。

笼统语言详细化

然而，代码的笼统性往往决定了它很难被简化。程序员一般都力求代码详细化以保证其简单易懂。

复杂代码简单化

考虑到主要矛盾是编写文本的复杂性，人们尝试着开发了许多图形化编程语言。例如Scratch（麻省理工学院的“终身幼儿园团队”开发的图形化编程工具，主要面对青少年），只需稍做改变就可以实现不同逻辑。

然而，鱼与熊掌不可兼得。简单易操作的语法架构通常难以实现复杂场景的逻辑，反之亦然，一些领域特定语言（DSLs）又因其强针对性而难以推广到其他领域。

用配置取代代码

许多“零代码”拥护者通过使用Zapier这样的工具将不同的应用程序整合集成在一起来使事情变得简单。

然而，这么做会有两个缺陷：

第一，逻辑被分散到不同的应用程序中从而使反向推理变得困难。

第二，也是更重要的一点，逻辑由不同应用程序的配置而非编写某种详细代码实现会使得其性能表现受制于这些应用程序的水平。于是，程序员经常面临这样的窘境：我们是信任外部系统并在其中投入大量的配置工作，还是尝试自己处置更多的代码逻辑？

逻辑不会消失。因而将其嵌入到Zapier规则的布线中并不能减轻任何维护和测试的负担。

代码的等价性

软件开发人员仍然使用纯文本的编程语言是有原因的，主要是为了进步工作效率和流程的简洁性。毫无疑问，假设有很多更好的工具呈现，软件开发人员会像扔烫手的山芋一样放弃文本。

然而，不同的逻辑表示方式并不意味者逻辑自身的简化，就像“2”和“two”来表达“两个”的性质一样。当然，实现商业逻辑的方式还有很多种。

也就是说，在可视化开发环境中的这个过程：

可以完全等同于：
def process_email(self, address): if not self.validate_email(address): raise InvalidDataException(_("Address is not valid")) self.store(address)
第一种方法要求开发人员熟悉图形化的工作界面，第二种方法要求熟悉文本形式的编程语言，两种方法都需要开发人员理解逻辑的内在关联，而且都简单易学。

为了更好地理解软件，开发人员通常需要在脑海里建模仿真，预测其在不同工作环境下的反响。

这和许多人在使用现代数字化设备时遇到费事的原因完全一样，所谓“VCR”问题就是指因为硬件的输入按钮很少，但内部工作非常复杂，因而用户需要在脑海中保留设备内部状态的高级模型。

这听起来有点不大现实，因为照“心智理论”来说，貌似只要懂技术或者擅长编程的人才会买数字化设备，而一般人想要用这些设备要先经过专业的训练。从这个层面上来讲，编程语言是文本或是图形化的都无所谓。

“零代码”不是一个好的趋势吗？

毫无疑问，“零代码”是一个好的趋势。

纵观历史，我们发现，计算机编程语言的开展仍道阻且长。

因而，我们仍然应该尝试改善我们的语言和环境。考虑以下两段代码
#include <string.h>#include <stdlib.h>char *add_domain_name(char *source) {const size_t size = 1024;char *dest = malloc(size+1);strncpy(dest, source, size);strncat(dest, "@example.com", size);return dest;}

和这个：
function add_domain_name(username: string): string {return username + "@example.com";}
第一个是段C语言代码，第二个是TypeScript代码。事实上，这两种语言的语法大致都相同，但是TypeScript比C更好用，因为开发人员无需担忧内存分配或者字符串的编码特性之类的事情。

事实上，对于一个足够完备的应用程序，其商业逻辑是非常强大的，以致于实现其的不同编程语言之间的差别可以忽略不计。显然，编程语言的开展并没有获得很大的进步。

“零代码”面临的困难

眼下，已经有一些很优秀的”零代码”平台呈现，例如被誉为“软件终结者”的Salesforce Cloud，它可以实现编程、根底规则设定和配置的可视化。

项目通常以“原型”开端，以标明平台可以做到这一点。这些内容汇总起来很快，大致可以完成项目的80％。遗憾的是，胜利并不能一蹴而就正如程序员所知：细节决定成败。

当平台无法实现一些功能时，开发人员通常需要自己构建详尽的处置办法，有时候也许根本无法处置。比如，我曾经使用平台搭建过一个自动响应电子邮件的程序，但是这个程序无法配置在检测垃圾邮件的程序后面，也无法检测到SMTP邮件，因而，它是不能用的。

即便平台可以自动修复Bug并顺利的实现逻辑，你仍然会遇到困难。例如，改善逻辑。

通常的代码程序需要改进时，开发人员会编写一段代码，然后把它部署到一个独立的环境中停止测试，测试胜利之后在将其部署到整个商业逻辑的代码中，或者，直接把它部署到整体代码中然后在一步步伐试，由此进步了应用程序的容错性并把对用户的影响降到最小。

而“零代码”加强了程序的专有性，因为，你几乎不能把同一个更改从一个项目准确的复制粘贴到另一个项目。即便Salesfoce提供了相关功能，“零代码”的这种缺点仍然很明显。

“零代码”的优势

弄清楚软件需求是件很重要的事。而“零代码”平台擅长交融不同的软件，这些软件的价值会随着交融而不时彰显。

“零代码”平台作为非IT系统，不只能让终端用户亲身参与到软件设计的过程中还可以及时搜集到用户反响。即便所谓灵敏的传统开发团队，也很少能做到让终端用户参与其中。于是“零代码”平台的这一优势显而易见。

还有很多实质上非“零代码”系统的平台，但是用户也能在其中发挥其主观能动性。例如我的最爱Looker(商业智能软件和大数据分析平),和一些类似的平台。有趣的是，在这些平台中开发的模型大都是利用普通的软件开发工具以纯文本的形式呈现的，这或许就是它们胜利的秘诀。

结论

用“零代码”平台替代主流的软件开发工具迄今仍然是梦想。纵观过去70年的开展，没有任何迹象标明这一梦想会很快被实现。

当然，各种“零代码”平台的呈现并非没有价值，但必需慎重对待。它并非是软件开发的灵丹妙药，而且有可能使事情变得更糟。

相关报道：

https://www.alexhudson.com/2020/01/13/the-no-code-delusion/

看起来太特 · 发表于 2023-4-20 14:23:55

关注

Happy柠檬 · 发表于 2023-4-20 14:24:47

转发了