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

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

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

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

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

为什么要“零代码”？

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

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

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

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

整个项目的更新迭代将由软件完成从而节省了人力成本。发布一个新的软件明显比重新修改流程和培训工人轻松得多。创新使企业在竞争同行中脱颖而出。当所有企业的想法都一致时，整个行业的服务会变得单一而平庸。这对一些企业来说不算什么坏消息，但消费者可不一定会喜欢。

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

“零代码”解决了什么问题？

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

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

不幸的是，这个问题已经被仔细研究过很长时间了，却没有被很好地解决。

抽象语言具体化

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

复杂代码简单化

考虑到主要矛盾是编写文本的复杂性，人们尝试着开发了许多图形化编程语言。例如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”问题就是指因为硬件的输入按钮很少，但内部工作非常复杂，因此用户需要在脑海中保留设备内部状态的高级模型。

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