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

标签：处理   状态   不能   商业   res   规则   ddr   简单   消费   

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

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

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

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

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

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

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

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

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

抽象语言具体化

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

复杂代码简单化

考虑到主要矛盾是编写文本的复杂性，人们尝试着开发了许多图形化编程语言。例如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年的发展，没有任何迹象表明这一梦想会很快被实现。

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

更多Linux资讯请查看：https://www.linuxprobe.com

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

标签：处理   状态   不能   商业   res   规则   ddr   简单   消费   

原文地址：https://www.cnblogs.com/linuxprobe0001/p/12426394.html