03

国内有专业的低代码平台吗

国内看似已经有很多低代码平台，道一云之前做个一个系列测评，T研究、海比等也都出过分析报告，但只要我们对照上述标准就不难看出，虽然低代码舆论很是喧嚣，但迄今为止应该说国内还很少有专业的低代码平台。

比如阿里今年一直鼓吹的宜搭，宣称是“低代码”应用搭建平台，但其实是一个“表单驱动”的“无代码”平台。阿里其实是打了个擦边球，说宜搭是“搭建”平台，没说是“开发”平台，你要说他过度宣传也算不上。但“搭建”和“开发”二字之差，差距可大了，“搭建”的意思是基于一些成熟模块组装应用，一旦遇到既有模块不够用的时候就歇菜。

国内很多分析报告提及的产品大部分我都瞄过，但看一圈下来，个人认为也就ClickPaaS可能还够得上（我也不确定，因为ClickPaaS不开放用户手册，没深入研究），毕竟它有模型驱动和开放集成，其他的门槛都够不上。

这么混乱的状态让我们的CIO们可怎么办呢，这再次说明如果缺乏有效的标准筛选真正专业的低代码平台，势必低代码和无代码一锅粥，结果大家都被搞得稀里糊涂。

04

低代码真的是新瓶装旧酒吗

关于低代码还有一种流行的观点是新瓶装旧酒，说二十年多年前的Delphi、PowerBuiler（后称PB）早就是低代码，但早就被时代淘汰了，今天的低代码也没戏。说这些话的大概率还是前辈。

要讲清楚这些问题得稍微digg一点历史，当年的Delphi和PB可是神一般的存在，因为相比同时代的其他技术（比如诘屈聱牙的MFC）来说易用性好太多，这俩不知道做了不知道多少企业信息化应用。随手翻看一本《Delphi开发典型模块大全》，里面尽是板材排料、进销存、文档管理、批发零售、房地产信息管理等案例。

这俩后来被时代淘汰，主要是因为时代变了，没跟上。互联网时代来了后，软件架构很快就从桌面端的C / S变成Web端的B / S，再后来是移动App。Web应用和App对前后端的要求比桌面应用都要高很多，因为大家做网页或App都是要勾引用户主动来访问啊，不像桌面端的企业应用就算不好用你为了工作也得用。互联网的这个二十年，技术栈发展的越来越复杂，新的低代码技术只能一直慢慢酝酿。

但经过OutSystems等厂商经过十多年的积累，今天的低代码技术已经远胜当年的Delphi和PB。今天的低代码要“低”的多，当年的Delph、PB等如果按今天的标准，连入门的资格都没有。

我们就以当年最流行的Delphi为例，Delphi虽然号称“可视化编程语言”，但也就是实现了界面的可视化开发和数据库的ORM，所有的逻辑都是要用代码写的，包括怎么把数据显示在表格也都要写代码。我们说的六大标准里，头两位的模型驱动、可视化开发这些都没有。PB也就比Delphi稍好一点，它核心的DataWindow可以无需代码做出增删改查，算是迈入模型驱动的门槛，但它不支持实体关系，模型驱动能力并不完整。同时PowerBuilder也没有可视化的逻辑开发，按今天的标准也只能在门槛徘徊。

贴两张老图让大家感受一下当年炸子鸡—Delphi。

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

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

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

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