万字长文讲透低代码

按规则这篇应该叫做“数字技术名词解释—低代码”，但之前的名词解释篇都是一两天草就，这篇磨蹭了半个多月，七七八八写了过万字，于是做一把标题党。

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

鉴于这个领域现在实在太乱，希望大家能多转发一下，让更多的人正确理解低代码。

01

低代码和无代码是两回事

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

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

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

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

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

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

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）表达式语言

表达式语言也有更平易近人的设计，比如我们轻舟就是用类似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年，那时候不开发企业应用开发什么呢/p>

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

首先，低代码技术达到成熟状态的时间并不长，即便是OutSystems。OutSystems虽然都成立20年了，但低代码表面看似简单，其实是一个相当复杂的技术体系，背后涉及核心的编程语言层面的设计，比如DSL、类型系统、泛型等等，还有怎么diff、debug、undo，都不容易。另外低代码平台还需要不断追赶这20年变化极大的技术环境。20年前是C / S、.Net，后来流行B / S、Java，再后来又得搞App，操作系统从Windows变成Linux，现在又面临从SOA到微服务的转型。OutSystems的主任工程师Tiago Sims曾介绍过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比赛的吧。这里有个细微的地方是要区分是业务逻辑比较复杂还是算法逻辑比较复杂，业务逻辑复杂对低代码来说不是问题，算法逻辑复杂才是问题。那啥叫业务逻辑复杂呢，就是业务人员总之是说的清楚，或者是能理解的；啥叫算法逻辑复杂呢，就是业务人员只能给个目标，具体怎么实现是不管的，就算解释也是一脸闷逼的听不懂的。

• 头部互联 级应用：头部互联 应用用户量巨大，为了优化性能有很多很多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们应该从试点应用做起，通常来说要求自己的团队用低代码的阻力会很大，但可以要求乙方用低代码，降 价。对乙方，我觉得短期很难卖平台，最好是和甲方谈个人力外包模式，避免项目制的僵化。业界说低代码是“高级外包”倒也没说错，虽然我觉得既然用的是低代码应该叫“低级外包”更合适。

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

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

(未完待续，还有一个很有意思的话题没讲，就是程序员要不要怕被低代码抢饭碗，找时间再慢慢写）

文章知识点与官方知识档案匹配，可进一步学习相关知识算法技能树首页概览33897 人正在系统学习中