低代码，要怎么低？和低代码有关的 10 个问题

或许是由于 Mendix 和 Outsystems 的收购及融资，还有 Gartner/Forrester 的鼓吹（Gartner 甚至预测 4 年后低代码开发会占应用开发的 65% 以上，你敢信？），这两年低代码突然开始受到关注，很多公司在开发这方面的产品，咱们也将 amis 开源项目的介绍改为了「前端低代码框架」，并推出了包含先后端的低代码平台「爱速搭」，本文将谈谈我对低代码的理解，尝试回答这个 10 问题：css

低代码是什么？html
以前是否有低代码平台？它们是怎么作的？前端
低代码究竟能解决什么问题？git
低代码平台适合用在什么地方？程序员
低代码平台会带来什么新问题？github
低代码平台的难点在哪？web
前端如何低代码？算法
后端如何低代码？数据库
低代码平台是否会大量取代研发？django
将来会怎样？

低代码是什么？

按维基百科的说法，低代码这个称呼是 Forrester 在 2014 年提出的，指那些用可视化方式建立应用的平台，特色是代码量比传统开发少得多，甚至无代码，因此能显著提高开发效率。

这个定义比较模糊，使得低代码平台有各类各样的形式，我见到的就有如下几种：

在线 IDE 和编辑器，界面方面虽然有可视化设计，但须要二次开发才能用。
提供一站式开发平台，提供了持续集成、部署和运维等功能，包含开发全流程。
简化前端开发，界面方面能够作到不用写 JavaScript。
简化后端开发，能够在线设计数据结构，并实现增删改查功能。
完全简化先后端开发，甚至变成无代码平台，什么均可视化编辑，易用性好，但牺牲了灵活性，这里面有不少子分类，好比 BPM、OA 系统、APP 开发等。
围绕某个成熟产品扩展功能，好比 CRM、ERP 之类的产品，为了知足定制需求，提供定制开发功能。

为何会有那么多种形式？在我看来主要和团队定位有关，有个「康威定律」是这么说的：

"设计系统的架构受制于产生这些设计的组织的沟通结构。" ——M. Conway

好比公司内有两个独立的小组，那整个系统设计确定会划分出两个独立的模块，相互之间有明确的界限，这也影响了对于低代码平台实现方式的选择。

若是是前端团队，通常会选第 1 种形式，不多考虑第 3 种，由于团队成员都会 JavaScript，不必弄个不用写 JavaScript 的产品，更不会考虑第 4 种，由于不负责后端开发。

若是后端的团队，就会选择第 4 种，由于只负责后端开发。

若是是大公司内的工程团队，由于职责是负责开发环境，因此会选择第 2 种形式，但这种形式通常有不少定制功能，而且依赖公司内部基础设施，致使只能在内部使用。

若是是创业公司，每每会选择第 5 种形式，面向外部固然是先后端都封装起来更简单，但可能过于追求「无代码」，致使虽然用起来简单，却失去了灵活性，只适合简单应用。

若是公司自己有成熟产品了，天然是选择第 6 种方式，围绕这个产品来扩展更有优点。

所以下次在了解一款低代码产品前，先了解它背后是什么团队，擅长作什么，团队背景将在很大程度上决定这款产品的侧重点。

以前是否有低代码平台？它们是怎么作的？

在低代码这个名词出现前早就有各类提高开发应用效率的产品了，好比我知道最先的是 FileMaker，它在 1985 年就出现了，发展历史几乎和这几十年的计算机技术同步，最先是 DOS 下的程序，苹果推出 GUI 操做系统 Macintosh 以后改为了 GUI 程序，在 2010 年移动时代推出了手机版的 FileMaker Go，而后在 2016 年推出了云上版本 FileMaker Cloud，最新版本又加入了人工智能。。。

FileMaker 最初定位是个数据库，但它在数据库的基础上扩展了应用开发功能，使得能够基于它开发应用，好比下图是用它编辑应用界面的例子：

FileMaker

相似的还有 Microsoft Access，也是很是古老的软件，1992 年就发布了：

Access

Oracle 在 2004 年也搞过一个叫 APEX 的东西，基于向导的方式生成几种固定模板页面，虽然灵活性差但用起来简单，最近也改叫低代码了。

Oracle APEX

另外就是本文的配图，来自 Visual Basic 6.0，1998 年发布的，功能比如今的许多低代码平台都强。

29 年前的 Visual Basic 6.0

还有著名的 SaaS 软件 Salesforce，十几年前就能够扩展字段来扩展功能，能够看到界面仍是 web 1.0 时代的风格：

Salesforce

另外还有不少商业产品，它们几乎都有十年以上的历史，最近才改叫低代码平台。

而相似 amis 这种经过配置生成后台页面的方式，我最先是在 Django 框架里看到的，它从 2005 年开始开发，下面是一个例子，用于定义数据模型字段：

from django.db import models

class Question(models.Model):
    question_text = models.CharField(max_length=200)
    pub_date = models.DateTimeField('date published')

有了这个定义，Django admin 插件就会自动生成管理后台页面，好比下面是新增一个问题的表单：

Django Admin

但 Django 这种实现方法有不少限制，加上先后端没分离，因此十几年过去了没什么改进。

低代码究竟能解决什么问题？

对于这个问题，有两种极端，专业开发者会认为低代码平台是个玩具，没什么用，而小白又觉得有了这个彻底不懂写代码也能开发应用，但这两种想法都不太正确。

要回答这个问题，首先按《人月神话》里的说法将软件开发进行分类：

全部软件活动包括：
根本任务--打造构成抽象软件实体的复杂概念结构。
次要任务--使用编程语言表达这些抽象实体，在空间和时间限制内将它们映射成机器语言。

这个分类最先出如今 1986 年做者的论文里，年代久远可能看过的人很少，这里多说两句，「根本任务」指什么？举个例子，好比要实现一款发工资的软件，里面涉及到如何计算所得税，那就得实现我的所得税的计算方法，用什么语言实现这个算法属于「次要任务」，而这个算法自己属于「根本任务」，不管用什么方式实现，你都不可能下降这个算法复杂度，好比我的所得税有 7 个层级，那就必定在某个地方有 7 个 if 语句。

「根本任务」没法解决，由于它就是需求自己，惟一解决办法是砍需求。

低代码平台主要解决的是「次要任务」，用更简化的方式来实现一样的功能，好比前面那个问题，在低代码平台中常见有这几种作法：

提供一种简化的 DSL，相似 Excel 里的公式。
提供图形化代码编辑器，相似 Unreal Engine 里的「蓝图」，或者相似 Blockly/Scratch 那种拼图的方式。
支持写代码或外部 api 来扩展。
平台内置实现，好比前面提到的我的所得税，平台能够内置一个专门算这个的函数。

其中 DSL 的方式只适合简单场景，由于 DSL 通常不具有复杂的逻辑控制、定义函数等功能，DSL 中要加入这些功能还不如直接用成熟的语言，好比 JavaScript/Lua。

不少低代码平台使用的是第 2 种方式，这种方式看起来最符合低代码平台的定义，也看起来最高大上，以 UE4 里的蓝图为例，这是我见过最复杂的可视化代码编辑器，能够用它来编写着色器和控制游戏流程：

UE4 的蓝图编辑器

根据 Epic 国内社区经理的说法，蓝图在实际开发中用得更多，个人我的体会是这种编辑器有如下几个好处：

方便预览，尤为是写着色器时能够立刻看到每一个节点的输出，这点比代码有明显优点。
解决了编程环境问题，不须要花时间配置环境。
节点会列出参数和属性，这样就不须要像写代码那样查手册了，直接点选就能够修改。
调试能实时生效，好比拖动某个数值立刻能看效果。
不容易犯错，好比须要符合类型才能连线，由于整个环境是可控的，在不少细节上能够比代码报错跟友好。
最重要的是：蓝图比 C++ 简单得多，也不像 C++ 那样须要多年经验，所以对人员的要求更低，跟容易招到人。

图形化编程在三维设计领域取得了很多成绩，好比 Blender、Grasshopper、Houdini、NUKE、Substance Designer 等，经过节点编程的方式极大提高了灵活度，但这些都是针对特定领域优化，并非通用编程方式。

对于通用编程领域使用节点编辑器是否可行？《人月神话》里也提到过图形化编程，原文是这样说的：

流程图是一种很是差劲的软件结构表达方式。实际上，它最好被视为是 Burks, von Neumann 和 Gold stine 试图为他们说设计的计算机提供一种当时迫切须要的高级控制语言。现在的流程图已经变得复杂了，一张图有若干页，有不少链接点，这种表现形式实在使人同情。流程图已经被证实是彻底没必要要的设计工具--程序员是在开发以后，而不是以前绘制描述程序的流程图。
更加基本的是，如咱们上面所讨论的，软件很是难以可视化。即便用图形表达出了流程图、变量范围嵌套状况、变量交叉引用、数据量和层次化数据结构等等，也只是表达了某个方面，就像盲人摸象同样。

这本书里预言的是 10 年内不会有突破性进步，然而过了 34 年的今天也没见明显进步，1985 年 Raeder 在他的文章里告诉咱们流程图最先是给汇编语言用的，由于汇编代码里都是跳来跳去的，看着容易晕，有这样的图能够看起来更清晰：

但在高级语言下就不须要这个了，由于高级语言下的代码可读性和这张图是同样的，但在复杂业务逻辑下用图形连线会很乱，对于熟悉看代码的开发者来讲效率反而下降了，后来在《人月神话》20 周年记念版里增长了这样一句话：

流程图是被吹捧得最过度的一种程序文档。详细逐一记录的流程图是一件使人生厌的事情，并且高级语言的出现使它显得陈旧过期。

因此这几种方法里我最倾向的是第 3 种，直接经过代码扩展功能，目前排名靠前的低代码平台都支持代码扩展，好比 Salesforce 和 ServiceNow，尤为是 ServiceNow 在先后端都使用 JavaScript，后端用到了 Rhino 引擎。

若是需求很常见，能够选择第 4 种方法，有些低代码平台针对某个垂直领域作了优化，集成了许多这个行业常见的功能，在同一个行业中，一家公司要解决的「根本任务」，在另外一家公司大几率也会遇到，所以使用这种低代码平台能够明显下降成本。好比淘宝能够算是电商行业的「低代码」平台，它把各类电商相关的功能都集成进去了，同时还提供了店铺装修功能实现个性化设计。

低代码平台适合用在什么地方？

什么样的应用适合使用低代码平台？目前看来最适合的场景是面向企业内部员工（B2E）的应用，也就是企业内部的各类系统及平台。

虽然也有面向对外应用的低代码平台，好比建立移动 APP，但这种只有小公司才会用，由于对外应用通常是公司主营业务，须要很高的自主可控性，并且定制需求多，对展示的要求也很高，无法复用低代码平台中的组件，只能经过自定义代码扩展，但若是大量使用代码扩展就还不如彻底本身开发了。

以 amis 为例，它诞生的背景是有个产品线通过多年发展，内部有超过 100 个后台系统，几乎每加个大功能都须要对应的管理后台来配置参数或管理内容，但开发和维护那么多系统成本很高，之前端为例，在这 100 个系统里使用了 jQuery、Angular、Avalon、React、Vue 等各类框架的不一样版本，新人接手后发现要改个东西还得先去学某个框架的旧版，有的文档连接都失效了。

为了完全下降这些页面的开发维护成本，amis 使用了配置化的方式来生成，只须要 JSON 配置就能完成全部页面功能开发，不须要再依赖各类框架了，和以前比有明显改进，后来推广到了百度其余产品线，一共制做了 3.3w 页面，使用人数近 10w。

低代码平台会带来什么新问题？

尽管低代码平台能明显提高效率，但它也会带来新的问题，好比扩展性、难以支持复杂场景、性能等问题，但在我看来最大的问题是平台锁定，许多问题都是这点带来的：

平台使用本身内部独立的框架，须要额外的学习成本。
平台是个黑盒，不清楚内部如何实现，遇到 bug、性能等问题只能求助官方。
若是有的需求不能知足，须要等平台的排期升级。
信息分布在各处，不像本地代码那样方便全局搜索，对于不熟悉的新人每每得在各个界面里找半天，并且是功能越强大的平台越难找。
不方便多人协做，有的平台只提供少许环境，难以作复杂的分支管理。
平台后续发展是个未知数，哪天倒闭了怎么办？Google 4 年前发布了一款低代码建立 APP 的产品 Google App Maker，既能可视化建立界面，又能写 JavaScript 扩展功能，但它在今年 2 月份的时候宣布关闭，没法导出，用户只能本身重写一个，连 Google 的低代码平台都会关闭，其它小公司就更别说了。

低代码平台为何作不到开放？在我看来主要是两个缘由：

技术上的矛盾，为了实现低代码就得隐藏不少没必要要的细节，而这些细节有的依赖平台底层框架，有的依赖平台编辑器，这些都是低代码平台最核心的技术，无法开源。
商业上的矛盾，若是能方便导出，让使用者能够二次修改并部署到任意地方，低代码平台就变成离线开发工具了，只要一个账号就能开发无数应用，不利于商业化，所以甚至有的低代码平台只提供 SaaS 版本，只能在线使用。

平台锁定这个问题在国内更严重，有种说法是古代中国属于大陆农业文明，农业文明的特色是强调自给自足，能不求人就不求人，这个长期影响很难改变，因此国内公司一变大就但愿什么都本身掌握，信不过别人。

目前国内只有一个封闭的开发平台取得了巨大成功，这个平台是微信小程序，相比原生 APP 开发，微信小程序的开发成本更低，并且还跨平台，因此其实也能算是低代码，微信小程序就是很封闭，只能运行在微信上，还得使用专门的框架和工具，连注册帐号和发布应用都要人工审核，但依靠微信的影响力和用户量，这些都不是主要问题。

在这个问题上，咱们虽然也无法将爱速搭的后端开源，但将前端最核心的配置渲染器开源了：

https://github.com/baidu/amisgithub.com

低代码平台的难点在哪？

在我看来低代码平台的难点是如何同时知足易用性和灵活性，由于它们常常是冲突的，以低代码平台中必备的可视化页面编辑器为例，要怎么实现页面布局？主要有三种作法：

基于 flexbox/float 方式来布局，这种方式灵活性强，但牺牲了易用性，须要使用者至少懂点 css，否则用不明白。
基于绝对定位来布局，这种方式易用性强，想拖哪就拖哪，但又失去了灵活性，要支持多分辨率就得手机和 PC 单独编辑，并且很差实现根据内容自动撑开高度。
提供水平/垂直分栏的容器，经过它们组合来实现各类布局，这种方式处于上面二者之间，灵活性和易用性都不突出，只适合用在移动端或后台类的页面。

除了布局，还有另外一个问题是要不要支持自定义 class？不支持的话灵活性差，改个字体全部地方都要配一遍，而支持又致使易用性差，不了解 css 的用户会发现改了一个地方影响到别的了，要想不同还得新建一个 class，有理解上的成本。

咱们有一款制做站点和小程序的 SaaS 产品 AIPage，在开发前曾经调研过各类同类产品，从技术角度上看，前端工程师应该更喜欢 webflow，它几乎将全部 css 开发都作成了可视化编辑，至关于在线版的 Dreamweaver：

webflow 的 css 编辑

然而继续调研却发现，在几个建站产品里 webflow 恐怕是商业方面最差的，虽然从 google trends 看和其它竞品有数量级的差距。

Google Trends

而这个领域最成功的是连可视化编辑器都没有的 shopify，它须要使用 Liquid 模板来自定义页面，这个模板语法和十年前的 PHP Smarty 差很少，功能上还更弱点，从技术角度看彻底不如 Webflow 的编辑器强大，但 Webflow 去年估值 3-4 亿，我两年多前调研 shopify 的时候市值就有 100 多亿了，当时以为太虚高，然而如今市值是 1146 亿（2020-9-23）。

因此复杂灵活的可视化编辑器有可能吃力不讨好，那偏向易用性呢？有些低代码平台追求「零代码」，让普通人都能用起来，但这样会面临另外一个意想不到的强大竞品：「Excel」，对于普通人来讲 Excel 就是一个好用的数据库，能够添加数据、修改数据、查找数据、排序过滤等，还能作图表，无需开发应用就能管理数据。

前段时间在吴伯凡的课程里听到一个故事，原文是这样的：

雷军很吃惊地发现，小米的整个管理系统，就是采购部门也就是供应链部门抱着一台电脑，生产部门抱着一台电脑，销售部门抱着一台电脑，电脑里都是Excel，三个部门打开以电脑后就对数字，这就是小米的流程管理。
同行知道这些事情之后不相信，认为这是天下奇闻。一个一年生产几千万台手机的公司，管理流程居然是这样的，这种流程出问题也是很天然的。

但从另外一个角度看，这个故事却告诉咱们，小米刚开始几年仅靠 Excel 就能生产几百万台手机，创造几百亿流水了，所以不少时候 Excel 就足够了，目前有些在线编辑的 Excel 平台，还出现了相似 Airtable 那样的新型 Excel，还有专门作漂亮表单的 Typeform 等，甚至连 Notion 这个文档工具都内置一个小数据库，这类产品在易用性上远好于各类零代码平台。

Notion 的数据管理

对于易用性和灵活性间的取舍，咱们也在探索中，amis 一方面经过配置的方式低成本，另外一方面又但愿能支持更多场景，所以支持复杂的表单嵌套、交互，以及自定义组件等功能，总体来讲更倾向灵活性：

前端如何低代码？

前端开发的主要工做是界面、交互和业务逻辑，20 年前的 FrontPage 和 Dreamweaver 就实现了可视化编辑页面，但它们生成的代码远不如手写，后来随着前端重构的流行，开发者又回归到经过写代码来制做页面。

如今可视化页面编辑器主要用于制做静态原型，或者官网及落地页，不多用在先后端交互比较多的页面中，由于动态数据难以在可视化编辑器里展现，好比 if xxx 的时候显示 yyy 要怎么显示呢？因此界面开发效率提高主要靠 UI 组件库。

前端 UI 组件库十几年前就有了，好比 YUI 是在 2006 年发布，jQuery UI、Ext JS 也紧跟着在 2007 年发布了，咱们 10 年前也曾经作过 Tangram component，但这些组件库在产品线中用得很少，你想一想百度搜索、贴吧、知道、百科的各个页面中，有哪些东西是通用的？能想到的恐怕只有轮播图、弹出层、下拉菜单这几个，这些在总体开发中占比不高，即使都用上对总体效率提高也不明显，因此前面也提到低代码平台不适合用在面向用户的产品中。

但在企业应用中状况就不同了，这些应用页面类似度更高，大部分是表格表单，并且更重视功能而不是个性化展示，所以跟容易实现复用，好比相似下面的聊天窗口：

在企业应用里甚至能够简化成表格展示，第一列是时间，第二列是用户名，第三列是文本，虽然展示差了不少，功能倒是同样的。

然而 UI 组件库强依赖开发，并不能算低代码，要想低代码必须进一步下降成本，好比相似 amis 那种用配置化的方式，它和 UI 组件库有什么不一样？在我看来主要是这两点明显区不一样：

1. 突破前端圈的易用性。

不少 UI 组件库都会号称易用，但这个易用是有前提的，至少你得会 JavaScript，而 amis 由于只是写 JSON 配置，加上有可视化编辑器，它作到了能够不须要了解前端就能使用，在百度内部 amis 平台的使用者绝大部分都不是前端，这是通常 UI 组件库都作不到的。

是否能够给 UI 组件库加个可视化编辑器？以前也有不少人尝试过，但行不通，由于 UI 库必须用代码来链接各个功能，好比数据的加载和绑定、事件的处理等，这些功能难以使用可视化编辑器来实现。

2. 完整的界面解决方案。

UI 组件库通常只做为页面中的一部分，而 amis 实现的是完整页面的配置化，能够经过配置实现交互功能，还包括富文本编辑器、条件组合等组件。

后端如何低代码？

在后端方面，低代码平台主要能解决这几类问题：

系统开发通用性问题，好比
1. 登陆、账号/角色、权限管理
2. 页面路由和导航
3. 外部系统对接，有的还提供一种通用协议来连各类数据源
数据管理，增删改查
流程管理
开发及运行环境

其中最经常使用的是增删改查，要如何实现？目前见到有这 3 种方式：

基于表单，优势是用起来简单，只须要设计好表单就能够用了，但缺点是灵活性要弱，难以支持复杂的关系。
基于数据模型，须要先定义数据模型，优势是灵活性强，但易用性又差了，非开发人员使用会有成本。
提供 BaaS 服务，好比开源的 Parse，经过提供友好的 API 来实现用户管理、数据存取等功能，这种方式须要写后端代码，但灵活性高。

以咱们本身为例，「爱速搭」使用了数据模型方式，数据模型实际上是在数据库表的基础上的封装，全部修改操做会转成表结构的变动，因此用户最好能有点数据库基础知识，牺牲了易用性，为何要这样作？咱们的主要考虑是：

在灵活性方面和传统数据库开发是同样的，性能也同样，咱们但愿能支持各类类型的应用开发，而不仅是简单的办公场景。
开发者更熟悉关系数据库，有些低代码平台基于 MongoDB 来方便扩展字段，但主流项目开发中仍是使用关系数据库。
可使用 SQL 对数据进行修改和查询，不只了解的人多，还能很方便对接外部 BI 平台作数据分析。
方便接入现有数据库，爱速搭支持直连已有数据库，基于已有数据开发应用，无需先将数据导入到平台中。
减小平台锁定风险，使用传统数据库更容易将现有数据迁移出来，改为转成传统的开发方式，加上前端使用开源 amis 渲染，下降了平台锁定的风险。

「爱速搭」中的数据模型

流程也是低代码平台中的经常使用功能，好比用可视化方式设计审批流：

「爱速搭」中的流程设计

低代码是否会大量取代研发？

不会，缘由以下：

前面提到太低代码不适合开发面向客户（toC）的应用，在许多公司这部分才是最占人力的。
对于企业内部应用，低代码能够显著提高效率，但效率提高带来的不是人员减小，而是需求增多，不少以前中低优的项目终于排上了，前面提到百度内部的 amis 建立了 3.3w 个页面，这里面确定很多是效率提高后多出来的，由于百度没那么多作后台页面的前端人力。
低代码平台解决不了「根本任务」，图形化编程只适合特定场景，用它来作控制流还不如写代码，所以依然须要研发。

将来会怎样？

个人我的判断是：

图形化编程只能在特定领域成功，目前看来主要是和音乐及图形相关的软件。
面向普通用户的无代码平台发展会受限，不少时候还不如用「Excel」。
对于成熟的垂直领域，购买软件是成本最低且效果最好的选择，好比数据可视化，咱们的 Sugar 开发了好多年，而购买只需几万就能马上用上。
低代码在国内和国外会有明显区别，国内更喜欢私有部署而不是 SaaS 版本，技术锁定将会是在国内推广时的最大障碍。
低代码平台不适合用来开发面向客户的应用，之后也同样。
对于企业内部应用，低代码平台将会发挥重要做用，它已经被实践证实能够极大提高效率，很值得尝试。