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

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

1. 低代码是什么？

2. 之前是否有低代码平台？它们是怎么做的？

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

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

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

6. 低代码平台的难点在哪？

7. 前端如何低代码？

8. 后端如何低代码？

9. 低代码平台是否会大量取代研发？

10. 未来会怎样？

低代码是什么？

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

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

1. 在线 IDE 和编辑器，界面方面虽然有可视化设计，但需要二次开发才能用。 

2. 提供一站式开发平台，提供了持续集成、部署和运维等功能，包含开发全流程。

3. 简化前端开发，界面方面可以做到不用写 JavaScript。

4. 简化后端开发，可以在线设计数据结构，并实现增删改查功能。

5. 彻底简化前后端开发，甚至变成无代码平台，什么都可视化编辑，易用性好，但牺牲了灵活性，这里面有很多子分类，比如 BPM、OA 系统、APP 开发等。 

6. 围绕某个成熟产品扩展功能，比如 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 语句。 

「根本任务」无法解决，因为它就是需求本身，唯一解决办法是砍需求。

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

1. 提供一种简化的 DSL，类似 Excel 里的公式。 

2. 提供图形化代码编辑器，类似 Unreal Engine 里的「蓝图」，或者类似 Blockly/Scratch 那种拼图的方式。 

3. 支持写代码或外部 api 来扩展。 

4. 平台内置实现，比如前面提到的个人所得税，平台可以内置一个专门算这个的函数。 

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

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

UE4 的蓝图编辑器

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

1. 方便预览，尤其是写着色器时可以马上看到每个节点的输出，这点比代码有明显优势。

2. 解决了编程环境问题，不需要花时间配置环境。

3. 节点会列出参数和属性，这样就不需要像写代码那样查手册了，直接点选就可以修改。

4. 调试能实时生效，比如拖动某个数值马上能看效果。

5. 不容易犯错，比如需要符合类型才能连线，因为整个环境是可控的，在很多细节上可以比代码报错跟友好。

6. 最重要的是：蓝图比 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。

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

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

1. 平台使用自己内部独立的框架，需要额外的学习成本。

2. 平台是个黑盒，不清楚内部如何实现，遇到 bug、性能等问题只能求助官方。

3. 如果有的需求不能满足，需要等平台的排期升级。 

4. 信息分布在各处，不像本地代码那样方便全局搜索，对于不熟悉的新人往往得在各个界面里找半天，而且是功能越强大的平台越难找。

5. 不方便多人协作，有的平台只提供少量环境，难以做复杂的分支管理。

6. 平台后续发展是个未知数，哪天倒闭了怎么办？Google 4 年前发布了一款低代码创建 APP 的产品 Google App Maker，既能可视化创建界面，又能写 JavaScript 扩展功能，但它在今年 2 月份的时候宣布关闭，无法导出，用户只能自己重写一个，连 Google 的低代码平台都会关闭，其它小公司就更别说了。

低代码平台为什么做不到开放？在我看来主要是两个原因：

1. 技术上的矛盾，为了实现低代码就得隐藏很多不必要的细节，而这些细节有的依赖平台底层框架，有的依赖平台编辑器，这些都是低代码平台最核心的技术，没法开源。

2. 商业上的矛盾，如果能方便导出，让使用者可以二次修改并部署到任意地方，低代码平台就变成离线开发工具了，只要一个帐号就能开发无数应用，不利于商业化，因此甚至有的低代码平台只提供 SaaS 版本，只能在线使用。

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

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

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

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

 

低代码平台的难点在哪？

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

1. 基于 flexbox/float 方式来布局，这种方式灵活性强，但牺牲了易用性，需要使用者至少懂点 css，不然用不明白。 

2. 基于绝对定位来布局，这种方式易用性强，想拖哪就拖哪，但又失去了灵活性，要支持多分辨率就得手机和 PC 单独编辑，而且不好实现根据内容自动撑开高度。

3. 提供水平/垂直分栏的容器，通过它们组合来实现各种布局，这种方式处于上面两者之间，灵活性和易用性都不突出，只适合用在移动端或后台类的页面。

除了布局，还有另一个问题是要不要支持自定义 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. 1. 突破前端圈的易用性。 

很多 UI 组件库都会号称易用，但这个易用是有前提的，至少你得会 JavaScript，而 amis 因为只是写 JSON 配置，加上有可视化编辑器，它做到了可以不需要了解前端就能使用，在百度内部 amis 平台的使用者绝大部分都不是前端，这是一般 UI 组件库都做不到的。

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

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

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

后端如何低代码？

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

1. 系统开发通用性问题，比如

   1. 登录、帐号/角色、权限管理

   2. 页面路由和导航

   3. 外部系统对接，有的还提供一种通用协议来连各种数据源

2. 数据管理，增删改查

3. 流程管理

4. 开发及运行环境

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

1. 基于表单，优点是用起来简单，只需要设计好表单就可以用了，但缺点是灵活性要弱，难以支持复杂的关系。

2. 基于数据模型，需要先定义数据模型，优点是灵活性强，但易用性又差了，非开发人员使用会有成本。

3. 提供 BaaS 服务，比如开源的 Parse，通过提供友好的 API 来实现用户管理、数据存取等功能，这种方式需要写后端代码，但灵活性高。

以我们自己为例，「爱速搭」使用了数据模型方式，数据模型其实是在数据库表的基础上的封装，所有修改操作会转成表结构的变更，所以用户最好能有点数据库基础知识，牺牲了易用性，为什么要这样做？我们的主要考虑是 ：

1. 在灵活性方面和传统数据库开发是一样的，性能也一样，我们希望能支持各种类型的应用开发，而不只是简单的办公场景。

2. 开发者更熟悉关系数据库，有些低代码平台基于 MongoDB 来方便扩展字段，但主流项目开发中还是使用关系数据库。

3. 可以使用 SQL 对数据进行修改和查询，不仅了解的人多，还能很方便对接外部 BI 平台做数据分析。 

4. 方便接入现有数据库，爱速搭支持直连已有数据库，基于已有数据开发应用，无需先将数据导入到平台中。

5. 减少平台锁定风险，使用传统数据库更容易将现有数据迁移出来，改成转成传统的开发方式，加上前端使用开源 amis 渲染，降低了平台锁定的风险。

「爱速搭」中的数据模型

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

「爱速搭」中的流程设计

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

不会，原因如下：

1. 前面提到过低代码不适合开发面向客户（toC）的应用，在许多公司这部分才是最占人力的。

2. 对于企业内部应用，低代码可以显著提升效率，但效率提升带来的不是人员减少，而是需求增多，很多之前中低优的项目终于排上了，前面提到百度内部的 amis 创建了 3.3w 个页面，这里面肯定不少是效率提升后多出来的，因为百度没那么多做后台页面的前端人力。

3. 低代码平台解决不了「根本任务」，图形化编程只适合特定场景，用它来做控制流还不如写代码，因此依然需要研发。

未来会怎样？

我的个人判断是：

• 图形化编程只能在特定领域成功，目前看来主要是和音乐及图形相关的软件。

• 面向普通用户的无代码平台发展会受限，很多时候还不如用「Excel」。

• 对于成熟的垂直领域，购买软件是成本最低且效果最好的选择，比如数据可视化，我们的 Sugar 开发了好多年，而购买只需几万就能立刻用上。

• 低代码在国内和国外会有明显区别，国内更喜欢私有部署而不是 SaaS 版本，技术锁定将会是在国内推广时的最大障碍。

• 低代码平台不适合用来开发面向客户的应用，以后也一样。

• 对于企业内部应用，低代码平台将会发挥重要作用，它已经被实践证明可以极大提升效率，很值得尝试。

来源：oschina

链接：https://my.oschina.net/u/4864754/blog/4762419