万字长文讲透低代码

| 2021-08-24

原载于公众号「冷技术热思考」

低代码这个概念今年极火，争议也极大。有些人力捧，觉得以后“人人都是程序员”，，又有不少人嗤之以鼻，如有 ERP 老兵讥讽《低代码，不要以比“中台”还快的速度臭大街》，有 ThoughtWorks 中国某徐姓 CTO 怒斥《“行业毒瘤”低代码》，还有很多认为低代码是新瓶装旧酒，早已有之，或者无非就是个高级外包。可惜的是，无论支持还是鄙夷，各路专家写文都是“草就”，至今也没一篇三观正且详实的。阿朱的几篇三观是正，但行文也过于简明，可能懂的自然懂，不懂的还是不懂。

本文希望对这个当前动荡不安的领域做一点“不草就”的综合说明，想说清楚七大问题：低代码和无代码（也称零代码）是什么关系、怎么判断一个低代码平台是否专业、国内是否有专业的低代码平台、低代码是不是新瓶装旧酒、低代码真的搞不定专业的企业应用吗、低代码不适合开发哪些应用、低代码并非银弹。

01 低代码和无代码是两回事

第一步得把低代码和无代码分清楚，因为这俩差异巨大，但现在业界经常混为一谈，导致很多很多问题，比如双方争论但指的不是同一个事情，厂商的口径乱，行业报告的结果不能看。

低代码专指低代码应用开发平台（LCAP），是一个被业界广泛认可的概念，头部的分析机构如 Forrester 和 Gartner 都已经发布了多年低代码开发平台的报告。如下图所示，大家可以看到这两家的报告入选的产品都很接近，特别是头部的六家简直是一模一样。这说明低代码应用开发平台已经是一个比较成熟的市场。

但无代码的“通用”开发平台，目前看并不存在，据我看将来也不会存在。因为开发软件必然要编写逻辑，就必然要写代码，除非哪一天人工智能能做到自动写代码。

我觉得低代码和无代码的关系有点类似于关系数据库和 NoSQL。关系数据库专指一种特定的数据库，即便多家厂商的产品实现可能千差万别，但至少提供的功能很相似，都高度遵循 SQL 标准。低代码开发平台虽然今天的标准化程度还没关系数据库这么高，但无论是 Gartner 还是 Forrester 都已经开始给出比较清晰的筛选标准，如要支持通用场景（如 UI、逻辑和数据三层都要有）、要满足专业开发需求等，随着行业发展标准化程度肯定会进一步提高。NoSQL 则只要不是 SQL 都算，不管你是 KV、wide-column、文档还是图，都可以叫 NoSQL。NoSQL 这个词热了有几年，但现在不太讲了，因为市场格局开始清晰之后，大家就不会关注过于宽泛的 NoSQL，而是根据需要关注具体的类型。我个人认为无代码这个词将来也一样会慢慢淡出，虽然现在十二个门派很是热闹，但不出几年真正有影响力的门派肯定也不多，这时大家也就不关注无代码而是直接找具体的产品了。

本文后续只专注讨论面向通用应用开发的低代码。低代码不是一个想吸引业务用户的用语，业务人员见了“代码”两个字就吓跑了，再低也没用，如果业务人员写不了 100 行代码的话，那 10 行也一样写不了。低代码平台主要面向专业开发，这点已经是头部分析机构的共识，虽然 Forrester 之前走过弯路，曾经也发布过面向业务人员的低代码开发平台报告，但近两年已经不再发布了，只保留面向专业开发者的低代码报告。用户数据也说明这一点，21CTO 在《低代码开发可不低，用户仍需要与 IT 技术部门联手》一文中提到据某统计“只有 6%的低代码开发是由业务人员完成的”，OutSystems 的数据是 69%的用户是专业开发，宜创科技 CEO 宜博也曾说低代码面临“懂技术的看不上，懂业务的学不会”的尴尬。

所以无代码和低代码完全不同，无代码面向业务人员，低代码面向开发人员；无代码泛指多种开发细分领域应用的工具，低代码特指一种通用开发工具；无代码不被国际头部分析机构认可，低代码被广泛认可。

现在国内很多行业专家和分析机构经常把两者混为一谈，这对技术的价值衡量、甲方的技术规划和选型都造成很大混乱，我迫切希望大家能够把低代码和无代码区分开，集中研究具备通用能力的低代码平台。

02 专业的低代码长啥样

现在市场上鱼龙混杂号称“低代码”的产品很多，怎么才能快速区分是不是“专业”？很简单，找一个最专业的产品来对标。

哪个产品才是最专业的？我们可以先看为什么低代码这两三年才热起来？不是因为 Salesforce 这样的 SaaS 厂商，也不是 Appian 这类 BPMS 厂商，这轮低代码热其实主要是因为 OutSystems。OutSystems 虽然也早在 2001 年就成立，但之前一直“猥琐发育”，2018 年 D 融资了 $3.6 亿，才突然引爆市场。无论 Forrester 还是 Gartner 都把 OutSystems 列入领导者象限，阿朱说他最推崇的低代码平台就四个，OutSystems 也是其中之一。所以，OutSystems 就是专业低代码平台的代表。

对比 OutSystems 和很多国内所谓的低代码平台，我找出了六项区分度最高的判断标准：模型驱动、可视化开发、表达式语言、软件工程、开放集成和脚本语言。

（1）模型驱动

“模型驱动”可能是最明显的区分标志，因为刚好有一个也很流行的概念叫“表单驱动”。很多人搞不清楚这两个概念，但其实这两类产品挺好区分。

首先可以看用户手册，这样不用安装试用也能看出差别。使用模型驱动的平台比如 OutSystems、Mendix 的手册会有很大一章讲怎么做数据建模和处理，包括怎么定义实体、实体间关系、主键、唯一性、索引、数据怎么访问、筛选、分组、统计等等，还提供 SQL 或类似扩展。使用表单驱动的产品则往往手册第一章就是说明怎么定义各种表单，都是各种和界面相关的控件，比如单选多选下拉框、文本日期数字等。

其次可以看界面。下图是分别是模型驱动的 OutSystems 和某表单驱动产品的相关操作界面，大家看是不是很不一样。

（表单驱动）

（2）可视化开发

可视化开发不是拖拉拽做个界面（这只能叫可视化设计），而是有完整的可视化编程语言系统，能够编写业务处理逻辑。看 OutSystems 这类产品的文档，你会发现很多编程语言的基本构造都有，比如顺序 / 分支 / 循环 / continue / break、输入输出参数、局部变量 / 全局变量、struct 和 list、异常等。虽然这些东西都是拖拉拽完成，看上去没有密密麻麻的一行行代码来吓人，但也足以吓退业务人员。一下几张图都来自于 OutSystems，大家可以感受一下。

（怎么抛出和处理异常）

（3）表达式语言

表达式语言有些类似 Excel 里的公式，有表达式语言才可以做一些比较复杂的计算。下图是 OutSystems 的表达式编辑器，大家可以看到有各种操作符，还有很多内置函数，比如数学函数、字符串处理函数等。

表达式语言也有更平易近人的设计，比如我们轻舟就是用类似 Scratch 的积木块设计。两种设计功能上是等价的，积木块设计更容易上手，Power Fx 这样的设计写复杂表达式更方便。

（4）软件工程

专业的低代码平台需要提供测试、debug、版本控制等软件工程支持。开发软件都会出 bug（低代码平台基本消除了语法层面的 bug，但对语义层面的 bug 一样无能为力），需求也总是会变。所以测试、debug、版本控制这些支持也是必不可少的。OutSystems 为什么做的最好，我觉得跟它完善的 debug 支持是分不开的。下图是 OutSystems 的 debug 界面，看起来和专业 IDE 有的一拼。

（Delphi 的主界面，实现了用户界面的可视化设计）

（Delphi 的逻辑实现界面，得写代码）

士别三日当刮目相看，何况十多年。今天的低代码并不是新瓶装旧酒，而是新瓶新酒，里外都是新的。说新瓶是因为低代码这个概念是新的，说新酒是因为今日的 OutSystems 等专业低代码产品的能力已经远超二十年前 PC 时代的 Delphi 和 PB。

我想说低代码是新瓶装旧酒的人啊，看到特斯拉也会说新瓶装旧酒，不还是汽车吗，看到 iPhone 也会说新瓶装旧酒，不就是个手机吗，我就打打电话，发发短信。这些人啊，可能也不因为别的，可能就是因为年纪太大了。

关于低代码从 DOS 时代至今的发展脉络，阿朱在《低代码都快烂大街了，还有人在为低代码吵架》一文有详细介绍，感兴趣的可以看看。

05 低代码能开发复杂的企业应用吗

目前业界很多人认为低代码搞不定复杂的企业应用。如 ERP 老兵果总在《低代码，不要以比“中台”还快的速度臭大街》一文中认为低代码只适合用来做“简单的工作流和表单流转的应用”或“大型应用软件的功能延伸的开发”，认为“不适合开发复杂逻辑的核心业务”。然而果总并没有说为什么。“技术领导力”在《如何用低代码搞垮一家公司？》一文中认为低代码只适合“创新探索类”、“生命周期短的”等应用。同样，也没有给出依据。类似的言论还很多，但都有一个共性，就是只说低代码不行，不解释，而且很多时候还把话说的那个斩钉截铁。

很多人还真的把自己当回事啊。

企业应用听起来高大上，但其实几十年东西了，能有多复杂呢？界面不用很时尚，不用扛百万并发，也没智能推荐啥的高级算法，其实从软件开发角度看企业应用是比较简单的。企业应用的复杂主要是领域模型和业务流程比较复杂，但从前文我们可以看到，低代码平台在建模和逻辑方面的能力都是比较全面的，再通过脚本语言、开放集成等扩展机制，对于不方便低代码实现的地方，可以和专业代码开发协作实现。所以用低代码开发复杂应用，本质上没问题。

这也不是我一个人的观点，明道云 CEO 任向晖写过一篇《APaaS 搞不定复杂的应用，是这样吗？》，把企业应用的复杂性分解为数据、权限、流程、算法、集成、报表等六个维度，然后逐一给出解决方案。这才是实事求是的态度。我觉得任总的分析已经比较充分，我也不再展开说了。我相信任何人但凡不带偏见，深入分析的，都会发现企业应用并没有什么复杂性是低代码一定搞不定的。

而且用低代码平台开发这类应用，还有不少独特优势，如开发人员上手快（我们的经验是个把月就能用的很溜了），开发效率高，便于业务人员和开发之间的沟通（因为逻辑大多是可视化的），不容易形成孤岛（因为专业的低代码平台默认就会根据模型生成 API）。OutSystems 在其网站上特意强调：

OutSystems is well-equipped to build ERP and similar large, complex systems with the desired performance and scalability.

OutSystems 也有一些这方面的案例，做供应链、CRM、ERP 的都有。OutSystems 成立于 2001 年，那时候不开发企业应用开发什么呢？

但可能很多人会说，OutSystems 作为厂商当然这么宣扬，但目前用低代码开发复杂企业应用确实不多啊。没错，但我认为这只是时间问题。

首先，低代码技术达到成熟状态的时间并不长，即便是 OutSystems。OutSystems 虽然都成立 20 年了，但低代码表面看似简单，其实是一个相当复杂的技术体系，背后涉及核心的编程语言层面的设计，比如 DSL、类型系统、泛型等等，还有怎么 diff、debug、undo，都不容易。另外低代码平台还需要不断追赶这 20 年变化极大的技术环境。20 年前是 C / S、.Net，后来流行 B / S、Java，再后来又得搞 App，操作系统从 Windows 变成 Linux，现在又面临从 SOA 到微服务的转型。OutSystems 的主任工程师 Tiago Simões 曾介绍过 20 年来 OutSystems 的发展（https://medium.com/outsystems-engineering/whats-not-new-in-outsystems-a-product-timeline-c781acd400cb#），可以看到 OutSystems 一边一直到补功能，直到 2014 年的 9.0 版本支持数据聚合处理才算比较完整，另一边一直在努力追赶技术趋势，直到 2016 年的 10.0 版本一口气推出 Client-Side Logic、Local Storage、异步、Reactive 等功能才算对移动 App 有较好的支持。这玩意是不做不知道，一做吓一跳，我们是做了轻舟低代码才知道这个东西很难。

更重要的可能是非技术因素。大部分企业对 CRM、ERP 的定制需求还没那么高，相比用低代码从头开发来说，采用 Saleforce、SAP 这样的套装软件实施，再做一些二次开发是更合适的选择。这也解释了为什么 Saleforce、ServiceNow 这样的 SaaS 巨头都有自己的低代码平台，而西门子会收购 Mendix。另外 ERP 这样的企业软件实施强依赖咨询经验，这不是低代码能解决的，而业界有经验的咨询顾问显然更熟悉 SAP 这样的产品，也没有意愿改变。专业程序员对低代码抵触也非常大，好不容易练就一身武艺，用了低代码好像都没用了？业界越是宣传用低代码开发快多少倍，开发团队可能越抵触。

总之，业界流行说低代码不能做 CRM、ERP 这类复杂的企业应用，这一说法很多人讲，但都没有根据。从技术原理出发，低代码最适合做的恰恰就是企业应用。目前用低代码做复杂企业级应用的 case 还不是很多，是因为低代码技术也就刚成熟不久、定制需求还不够强（套装软件能满足）或者行业不愿做，并不能说明它做不了。

06 低代码不适合开发哪些类型的应用

很多专家啊，不但错误的认为低代码搞不定复杂企业应用，还在低代码适合哪些类型的应用上也说错了。

低代码真正不太擅长的，是那些有各种特殊要求的应用，比如：

对算法和复杂数据结构要求比较高的：我想不会有人想到用低代码平台去刷 LeetCode 题、打 ACM 比赛的吧。这里有个细微的地方是要区分是业务逻辑比较复杂还是算法逻辑比较复杂，业务逻辑复杂对低代码来说不是问题，算法逻辑复杂才是问题。那啥叫业务逻辑复杂呢，就是业务人员总之是说的清楚，或者是能理解的；啥叫算法逻辑复杂呢，就是业务人员只能给个目标，具体怎么实现是不管的，就算解释也是一脸闷逼的听不懂的。
对界面要求特别高的：比如游戏或抖音、云音乐这样的社交娱乐型的应用。目前主流的低代码平台都不擅长做酷炫的界面（也有一些特定类型的低代码平台如 App Onboard 是面向游戏开发的，不在本文讨论范围之内）。
头部互联网级应用：头部互联网应用用户量巨大，为了优化性能有很多很多 trick，前后台技术架构非常复杂，低代码平台的实现是比较标准的数据库 / 逻辑 / 界面三层架构，无法满足性能需求。注意这不是说所有互联网应用都不合适，只是指那些用户量特大的头部应用。
分析和智能化应用：分析类应用自然应该用更专业的 BI 工具，智能化应用也应该用更专业的机器学习平台等工具。
系统软件、科学计算等其他专业性很强的应用。这个不多说了，估计也没谁想用低代码来做，但多说一句，虽然这些系统的内核肯定不适合低代码开发，但界面可是很适合，我们轻舟低代码产品正是脱胎于云计算平台的界面开发。

现在大家应该可以发现很多业界流行的观点说低代码适合这个那个的其实也都是错的，比如：

说低代码适合“简单的工作流和表单流转的应用”：事实上专业的低代码并不见得特别适合这类应用，比如 Gartner 就说 OutSystems 这方面的支持还不太好。其实最适合这类应用的反而是那些“表单驱动”的产品，这些产品并非专业的低代码平台。专业的低代码平台搞这些也不是完全不行，但属于大炮打蚊子，性价比不高。
说低代码适合“生命周期短的应用”：事实上如果你用 OutSystems 这样“最专业”的低代码平台去做营销活动页这样“生命周期短的应用”，你肯定会欲哭无泪。为什么？因为营销活动页对界面的要求很高哎。
说低代码适合“创新型应用”：有篇文章按 Gartner 的方法把应用分成基础设施型（如 ERP）、差异化型（如 CRM）和创新型应用，说前两类应用低代码就别碰了，都是传统 IT 的菜，低代码就搞搞创新型应用，这个说法也不对。互联网 App 算典型的创新型应用吧，上面已经说过这个低代码搞不定。

07 低代码不是银弹，不要过度神化

上面我们说低代码很适合开发典型的企业应用，优点明显，如开发人员上手快、开发效率高、增进沟通和集成等，但也不要认为低代码是银弹，用了什么问题都解决了。原因主要有以下三个方面。

1）开发工具只能解决软件研发的部分问题。作为开发工具，低代码可以加快在需求比较明确时的软件交付，也可以在大方向比较明确但具体需求不明时加快软件的迭代更新。但企业应用和企业的经营管理方式、业务方向、业务流程、组织架构密切相关，和人密切相关，这些方面如果有问题，软件都不知道怎么做，这都不是开发工具所能解决，该请咨询还是得请咨询。低代码就像特种兵，单兵作战能力是强，但如果将帅不行，战略战术拉垮，也打不了胜战。

2）低代码能提升多少开发效率缺乏权威数据，不要有太高预期。业界有很多对低代码开发效率的宣传，最多的是说什么提升 10 倍啦，这些一看就是胡扯。一些厂商和分析机构会发布提效数据，看似效果特别好，但因为前面说的无代码和低代码没分清问题，这些数据不可信。比如阿里“宜搭”的数据说平均将应用开发成本从 17.5 人天提高到 3.5 人天，提效 500%，但前面说过“宜搭”是无代码工具。无代码工具因为都是面向特定类型的应用高度优化的，提效明显很正常的，但不通用。专业的低代码厂商如 OutSystems、Mendix，反而不敢宣传提效多少倍，所以一个厂商宣传的效果越好，就越不可能是专业的低代码平台。从我们的经验看，用低代码做一些小系统确实挺快，但上了规模后还能是不是有数倍提升，我觉得也不大可能。根据我们的初步经验，我们觉得提升 1 到 2 倍是一个比较合理的预期。

3）行业典型的项目制限制了低代码的价值。低代码平台因为可视化、效率高，最适合业务和开发密切沟通合作，快速迭代。但当前甲乙方之间典型的项目制要求双方提前签订详细的合同和 SOW，这就把本来可以敏捷开发的生生打回到瀑布模式，这样低代码快速迭代的价值就很难体现。项目制存在太久，不是一时半会改的了的。

08 小结

最后做个小结：

无代码和低代码不是一个层次的概念。低代码是以 OutSystems、Mendix 等产品为代表，主要面向专业开发的通用应用开发平台；无代码则是一个营销用语，用于形容很多种面向业务人员的工具，如应用搭建、在线表单、工作流等。不存在无代码的通用应用开发平台。无代码这个概念过于宽泛，未来很可能会慢慢淡出市场。

要判断一个低代码平台是否专业，可以重点看模型驱动、可视化开发、表达式语言、软件工程、开放集成和脚本语言等六个方面。对照这些标准，不难看出迄今为止应该说国内还很少有专业的低代码平台，虽然舆论甚是喧嚣。

业界关于低代码适用场景的观点大多数都是错的。比如业界很多人讲低代码搞不定复杂的企业级应用，但都毫无根据。从技术原理出发，低代码其实最适合做的就是企业应用，即便是 CRM、ERP 这样复杂的应用；业界认为低代码适合做“简单的工作流和表单流转的应用”、“生命周期短的应用”、“创新型应用”等观点也都是错的，这些应用很多恰恰不适合低代码。

低代码不适合做的应用是对算法、界面、性能、分析和智能化等专业性要求高的应用。

低代码对企业应用开发价值明显，但也不是银弹，不要过度神化。

对甲方来说，我认为 CIO 们应该从试点应用做起，通常来说要求自己的团队用低代码的阻力会很大，但可以要求乙方用低代码，降报价。对乙方，我觉得短期很难卖平台，最好是和甲方谈个人力外包模式，避免项目制的僵化。业界说低代码是“高级外包”倒也没说错，虽然我觉得既然用的是低代码应该叫“低级外包”更合适😄。

最后的最后，我再次呼吁分析机构能够区分低代码和无代码，聚焦分析面向通用应用开发的低代码开发平台，促进这个行业的认知统一，产品的标准化，这样才能够推动行业发展。

无代码将死，低代码长存！