作者 | Alex Hudson
译者 | 风车云马，责编 | 唐小引
封图 | 付费自东方 IC
最近几年里越来越流行一句话，“2020 年将是无代码的一年”。这意味着你即使不是软件开发人员，也可以编写业务逻辑甚至整个应用程序。这样做固然有一定的好处，有些“无代码”工具确实很强大，但我也认为这是不大可能的。
为什么会有“No Code”？
从表面上看，“不用代码”的原因是显而易见的：软件开发人员成本昂贵，供不应求，而且软件本身的开发也是需要周期的，后期还要根据需求变化进行调整，并且运行和维护的成本都很高。
然而对软件的需求是与日俱增的。现代数字化企业需要大量的软件，大部分都是高度定制的。
如果我们可以创建数字业务，甚至数字产品，那不是更好吗? 或许一开始新技术很难使用，但随着时间的推移会变得更容易获得。
将业务流程转换到软件领域主要有两个明显的好处：
“变更控制”成为一个软件问题，而不是人员问题。您仅仅做一个软件发布，而不需要通过大量的人员再培训，就可以改变现有的流程或引入新的流程。从而实现更快地回滚或迭代。 创新使企业与众不同，尤其是企业的竞争对手也在做同样的产品，将业务流程转换到软件领域，这对一些企业来说是好事，但大多数企业不想从事软件产品服务。许多企业试图通过数字化转型来获得这些好处，但都失败了。你会突然发现公司会变成（至少在某种程度上）一个软件开发公司，而大多数公司都不擅长这个! 虽然软件环境具有无限的可能性，但要有足够的资源（时间、金钱、人员），大多数人都会梦想各种可能性，但在实践过程中受到很多限制。
“无代码”是什么？
“无代码”意味着软件开发不需要编写代码。人们可以在某个“更高的层次”上进行操作，在这个层次上，开发要简单得多，但最终的结果是相同的。
具体来说，按照计算机编程语言的语法形式编写业务逻辑是令人讨厌的。打个比方：软件开发人员就像汽车修理工一样，了解引擎的内部。但大多数人只需要能够驾驶汽车，会使用方向盘和一些踏板就行。随着时间的推移，我们不断提高了机械化程度。有人可能会喜欢手动挡，但大多数人更喜欢自动变速箱，这样驾驶我们就让它简化了！
简单的抽象
在这个行业的早期试图简化编程就已经开始了：BASIC 是一种尝试，它允许人们用看起来像英语的语言来编写软件，这也是非常成功的。
然而，抽象作为编码系统的一个关键概念，它往往不会过于简化：实际上，许多开发人员都在积极地尝试确保代码足够具体，使其易于理解。
简单的语法
主要的问题是编写文本，已经有人尝试简化语法甚至完全去掉——有许多图形开发系统。
这些语法的简化也会带来表达的问题。一旦它们足够简单，可以快速掌握，它们就不再具有足够的表达能力，无法在许多场景中使用。还有些计算机语言专注于某个应用程序领域，称为领域特定语言(dsl)。但这些语言很少有真正在开发中获得成功的，主要是因为它们再次使事情变得极其复杂。
配置代码
许多不会写代码的人正在通过整合现成的应用程序来构建重要的系统。使用像 Zapier 这样的工具可以更直接地做到这一点，这些工具可以广泛地集成到不同的系统中。
这种情况有两方面的原因。首先，您已经将逻辑扩展到各种不同的系统中，因此很难再对整个应用程序进行梳理。
其次，逻辑是通过配置来实现，而不是代码。程序员经常面临这样的两难境地：我们是信任外部系统并投入大量的配置工作，还是尝试自己处理更多的逻辑？
无论应用程序如何扩展，逻辑不会消失。即使使用 Zapier 规则进行连接，也不会消除任何维护的成本或负担。
代码的等价性
开发人员仍然使用纯文本是有原因的——主要是为了提高效率和清晰的表达。当然，如果出现了更简洁的工具，许多（不是所有！）开发人员会像扔热石头一样丢掉文本。
但是无论以什么方式的逻辑表达，都不会减少所描述事物本身的复杂性。就比如编写“two”和“2”，表示相同的东西。
假想视觉开发环境中的过程是这样的：
完全等价于：
defprocess_email( self, address) :
ifnotself.validate_email(address):
raise InvalidDataException( _( "Address is not valid"))
self.store(address)
在第一个例子中，我需要知道该视觉环境系统是如何工作的。在第二个例子中，我需要了解一种语言和开发环境。但这两种技能都是很容易获得的。它们之间的共同点是，我要理解逻辑是什么，以及它将如何工作。
要理解软件——任何类型的软件——你需要能够在头脑中对所表示的系统建模，并基于此对它在不同场景下的工作方式进行预测。
这正是许多人在现代数字设备上遇到麻烦的原因。问题是由于硬件的输入按钮很少，但内部工作非常复杂:所以用户需要在他们的头脑中保留设备内部状态的高级模型。
有些人认为这是一种不可习得的技能。如果你不能推断出某物的内部状态，那么很可能将无法编程。我敢说没有大量的实践，你肯定做不好。坦率地说，逻辑是文本的还是可视化的并不重要。
“无代码”就不好吗？
绝对不是。
在 70 多年的可编程计算机的发展历史中，我们仍然在使用 20 年前的开发工具，这才是最大的不幸。
当然，我们仍然应该努力改善我们的语言和环境。看以下两段代码：
# include<string.h>
# include<stdlib.h>
char* add_domain_name( char*source) {
constsize_tsize = 1024;
char*dest = malloc(size+ 1);
strncpy(dest, source, size);
strncat(dest, "@example.com", size);
returndest;
}
以及这个：
functionadd_domain_name(username: string): string{
returnusername + "@example.com";
}
第一个例子是 C（发明于 1972 年左右），第二个例子是 40 年后的 Type（发布于 2012 年）。它们在很多地方有大致相同的语法，但是 Type 比 C 高级得多。特别是，开发人员不需要担心内存分配、字符串的编码或其他事情。
实际上，对于足够大的应用程序，大部分业务逻辑将在相当高的级别上实现，而且语言之间的差异将更加不明显。
在实践中，“无代码”的不足之处？
目前有一些非常高级的系统，例如，您可以在 Salesforce Cloud 中定义非常复杂的软件，而不需要编写任何代码。它包含了可视化编程、规则设置和配置。
对于其他人的平台，实际上根本无法实现所需的功能。您常常需要构建复杂的解决方案来弥补功能缺失。举个例子，我曾经使用过一个平台，它有一个电子邮件自动回复器，但是不能放在垃圾邮件检查器中。使用它意味着产生垃圾邮件反向散射，这是许多电子邮件系统迅速禁止的接收方式。
假设它能根据您的需求完全实现特性，那么随着项目的进展，在产品化方面就会遇到麻烦。变更控制就是一个明显的例子。
我们习惯于使用代码创建更改，然后将其部署到单独的测试环境中，最后部署到生产环境中（要逐步地启用该特性）。如果出现错误，我们可以快速地处理它们并解决问题，而不会影响到所有用户。
由于系统“无代码”，非生产环境中的测试往往很难或不可能实现。Salesforce 有一些优秀的工具可用来完成这项工作，即使在那样的环境中，这也是非常困难的。
“无代码”的成功之处？
质疑对软件的需求也无非好坏，“无代码”系统对于概念验证阶段有很好的指导作用。
作为非 IT 系统，它们在获取实际业务设计输入和反馈方面也非常有用。虽然我们谈论了很多关于敏捷开发的内容，但是我很少看到开发团队中的最终用户。
有许多工具，虽然本身不是“没有代码”，但也允许用户生成更多的技术输出。我最喜欢的例子是商业智能工具 Looker，在不同的细分市场中还有许多类似的工具。我发现它们的模型开发都是纯文本的，都使用常规的软件开发工具，这非常有趣。
总结
我认为“无代码”作为大多数主流开发的替代方案是一个白日梦。在过去的 70 年里，还没有出现任何先进的技术让我们敢于取代基于文本的开发。
作为一名软件开发 CTO，虽然我认为各种“无代码”工具非常有价值，但必须谨慎部署。它们不是软件开发的万能包，很可能使情况变得更糟而不是更好。
对我来说，最理想的用户是“超级用户”：那些已经非常熟练的 IT 用户，他们可能会设计出更好的工具，给他们一个交付的环境是极其重要的，但这应该是我们技术人员的共同努力——“有/无代码”双方不应该对立。
原文：The 'No Code' Delusion
链接：https://www.alexhudson.com/2020/01/13/the-no-code-delusion/
作者：Alex Hudson，Fractional CIO/CTO at Freeman Clarke
译者：风车云马
【END】
你觉得无代码开发靠谱么？