万字长文讲透低代码 | IDCF
共 11294字,需浏览 23分钟
·
2021-07-10 07:26
来源:冷技术热思考
作者:风轻扬
低代码和无代码(也称零代码)是什么关系? 怎么判断一个低代码平台是否专业? 国内是否有专业的低代码平台? 低代码是不是新瓶装旧酒? 低代码真的搞不定专业的企业应用吗? 低代码不适合开发哪些应用? 低代码并非银弹。
一、低代码和无代码是两回事
第一步得把低代码和无代码分清楚,因为这俩差异巨大,但现在业界经常混为一谈,导致很多很多问题,比如双方争论但指的不是同一个事情,厂商的口径乱,行业报告的结果不能看。
低代码专指低代码应用开发平台(LCAP),是一个被业界广泛认可的概念,头部的分析机构如Forrester和Gartner都已经发布了多年低代码开发平台的报告。
如下图所示,大家可以看到这两家的报告入选的产品都很接近,特别是头部的六家简直是一模一样。这说明低代码应用开发平台已经是一个比较成熟的市场。
相反,分析机构对无代码的态度就很微妙了。虽然也有一些分析机构也提无代码开发平台的概念,如G2(当然更不用说目前混乱的国内分析机构),但Forrester和Gartner从未发布过无代码开发平台的报告。
Forrester和Gartner倒也不是说无代码是个伪概念,他们的共识是无代码这个词只是一个营销用语,主要用来突出一个工具无需编程基础,消除业务用户的恐惧。
‘No-code’ is a marketing term, implying the tool is for non-professional developers.
— By Gartner
(https://appian.com/resources/resource-center/analyst-reports/gartner-quick-answer-low-code-vs-no-code-dev-tools.html)
Businesspeople hankering to deliver their own apps love the “no-code” message. Thus, “no-code” has become a marker for products aimed at empowering business users. However, customers report that even powerful low-code platforms in some cases can’t produce apps without any coding. So what does this mean for the “no-code” promise?
— By Forrester
(https://go.forrester.com/blogs/watch-your-language-low-code-and-no-code-are-not-the-same/)
无代码这个词通常用来形容一些细分领域的开发工具,最常见的是应用搭建平台(国外一般叫App Builder之类),如国外的Appy Pie、国内的宜搭、简道云等,还可以用来形容Airtable / AppSheet / Treelab这类在线表单工具或轻流这类的工作流工具。这几类工具差别巨大,如下图所示,还有人将无代码和低代码的江湖分成十二个“门派”,由此可见无代码是一个相当宽泛的概念。
但无代码的“通用”开发平台,目前看并不存在,据我看将来也不会存在。因为开发软件必然要编写逻辑,就必然要写代码,除非哪一天人工智能可以做到自动写代码。
我觉得低代码和无代码的关系有点类似于关系数据库和NoSQL。关系数据库专指一种特定的数据库,即便多家厂商的产品实现可能千差万别,但至少提供的功能很相似,都高度遵循SQL标准。
低代码开发平台虽然今天的标准化程度还没关系数据库这么高,但无论是Gartner还是Forrester都已经开始给出比较清晰的筛选标准,如要支持通用场景(如UI、逻辑和数据三层都要有)、要满足专业开发需求等,随着行业发展标准化程度肯定会进一步提高。
NoSQL则只要不是SQL都算,不管你是KV、wide-column、文档还是图,都可以叫NoSQL。NoSQL这个词热了有几年,但现在不太讲了,因为市场格局开始清晰之后,大家就不会关注过于宽泛的NoSQL,而是根据需要关注具体的类型。
我个人认为无代码这个词将来也一样会慢慢淡出,虽然现在十二个门派很是热闹,但不出几年真正有影响力的门派肯定也不多,这时大家也就不关注无代码而是直接找具体的产品了。
本文后续只专注讨论面向通用应用开发的低代码。低代码不是一个想吸引业务用户的用语,业务人员见了“代码”两个字就吓跑了,再低也没用,如果业务人员写不了100行代码的话,那10行也一样写不了。
低代码平台主要面向专业开发,这点已经是头部分析机构的共识,虽然Forrester之前走过弯路,曾经也发布过面向业务人员的低代码开发平台报告,但近两年已经不再发布了,只保留面向专业开发者的低代码报告。
用户数据也说明这一点,21CTO在《低代码开发可不低,用户仍需要与IT技术部门联手》一文中提到据某统计“只有6%的低代码开发是由业务人员完成的”,OutSystems的数据是69%的用户是专业开发,宜创科技CEO宜博也曾说低代码面临“懂技术的看不上,懂业务的学不会”的尴尬。
所以无代码和低代码完全不同:无代码面向业务人员,低代码面向开发人员;无代码泛指多种开发细分领域应用的工具,低代码特指一种通用开发工具;无代码不被国际头部分析机构认可,低代码被广泛认可。
现在国内很多行业专家和分析机构经常把两者混为一谈,这对技术的价值衡量、甲方的技术规划和选型都造成很大混乱,我迫切希望大家能够把低代码和无代码区分开,集中研究具备通用能力的低代码平台。
二、专业的低代码长啥样
首先可以看用户手册,这样不用安装试用也能看出差别。使用模型驱动的平台比如OutSystems、Mendix的手册会有很大一章讲怎么做数据建模和处理,包括怎么定义实体、实体间关系、主键、唯一性、索引、数据怎么访问、筛选、分组、统计等等,还提供SQL或类似扩展。使用表单驱动的产品则往往手册第一章就是说明怎么定义各种表单,都是各种和界面相关的控件,比如单选多选下拉框、文本日期数字等。 其次可以看界面。下图是分别是模型驱动的OutSystems和某表单驱动产品的相关操作界面,大家看是不是很不一样。
(模型驱动,OutSystems)
(表单驱动)
(左:逻辑开发工具箱,注意有If、Switch、For Each流程控制;右:一个比较简单的逻辑)
(怎么抛出和处理异常)
![](https://filescdn.proginn.com/51a9a7df865f57c630719c77a597134e/f8ee4c30d57030b6afe03bdaf3979d65.webp)
表达式语言也有更平易近人的设计,比如轻舟就是用类似Scratch的积木块设计。两种设计功能上是等价的,积木块设计更容易上手,Power Fx这样的设计写复杂表达式更方便。
2.4 软件工程
专业的低代码平台需要提供测试、debug、版本控制等软件工程支持。开发软件都会出bug(低代码平台基本消除了语法层面的bug,但对语义层面的bug一样无能为力),需求也总是会变。所以测试、debug、版本控制这些支持也是必不可少的。OutSystems为什么做得最好,我觉得跟它完善的debug支持是分不开的。下图是OutSystems的debug界面,看起来和专业IDE有一拼。
理论上,有了模型驱动等上述四大功能,开发一个不是太复杂的独立应用就够了,但典型的企业软件都是相互依赖和集成的,所以平台还需要具备能够调用外部API和开放API给别人的能力。平台如果没有这两方面的功能,开发出来的应用相互之间都没法连通和集成,全是技术债。我们看国外关于低代码的文章,经常会看到一个词叫Shadow IT,说的就是这个问题。大家都胡乱地开发各种应用,还都集成不起来,将是一场大灾难。
An LCAP is characterized by its use of model-driven or visual development paradigms supported by expression languages and possibly scripting…
里面模型驱动、可视化开发、表达式语言、脚本语言都提到了。
小结,判断是不是"专业”低代码,可以重点看模型驱动、可视化开发、表达式语言、软件工程、开放集成和脚本语言等六个方面。
三、国内有专业的低代码平台吗
比如阿里今年一直鼓吹的宜搭,宣称是“低代码”应用搭建平台,但其实是一个“表单驱动”的“无代码”平台。阿里其实是打了个擦边球,说宜搭是“搭建”平台,没说是“开发”平台,你要说他过度宣传也算不上。但“搭建”和“开发”二字的差距可大了,“搭建”的意思是基于一些成熟模块组装应用,一旦遇到既有模块不够用的时候就歇菜。
国内很多分析报告提及的产品大部分我都瞄过,但看一圈下来,个人认为也就ClickPaaS可能还够得上(我也不确定,因为ClickPaaS不开放用户手册,没深入研究),毕竟它有模型驱动和开放集成,其他的门槛都够不上。
这么混乱的状态让我们的CIO们可怎么办呢,这再次说明如果缺乏有效的标准筛选真正专业的低代码平台,势必低代码和无代码一锅粥,结果大家都被搞得稀里糊涂。
四、低代码真的是新瓶装旧酒吗
关于低代码还有一种流行的观点是新瓶装旧酒,说二十年多年前的Delphi、PowerBuiler(后称PB)早就是低代码,但早就被时代淘汰了,今天的低代码也没戏。说这些话的大概率还是前辈。
(Delphi的主界面,实现了用户界面的可视化设计)
(Delphi的逻辑实现界面,得写代码)
五、低代码能开发复杂的企业应用吗
目前业界很多人认为低代码搞不定复杂的企业应用。
如ERP老兵果总在《低代码,不要以比“中台”还快的速度臭大街》一文中认为低代码只适合用来做“简单的工作流和表单流转的应用”或“大型应用软件的功能延伸的开发”,认为“不适合开发复杂逻辑的核心业务”。然而果总并没有说为什么。
“技术领导力”在《如何用低代码搞垮一家公司?》一文中认为低代码只适合“创新探索类”、“生命周期短的”等应用。同样,也没有给出依据。
类似的言论还很多,但都有一个共性,就是只说低代码不行,不解释,而且很多时候还把话说的那个斩钉截铁。很多人还真的把自己当回事啊。
企业应用听起来高大上,但其实几十年东西了,能有多复杂呢?界面不用很时尚,不用扛百万并发,也没智能推荐啥的高级算法,其实从软件开发角度看企业应用是比较简单的。
企业应用的复杂主要是领域模型和业务流程比较复杂,但从前文我们可以看到,低代码平台在建模和逻辑方面的能力都是比较全面的,再通过脚本语言、开放集成等扩展机制,对于不方便低代码实现的地方,可以和专业代码开发协作实现。所以用低代码开发复杂应用,本质上没问题。
OutSystems is well-equipped to build ERP and similar large, complex systems with the desired performance and scalability.
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还不是很多,是因为低代码技术也就刚成熟不久、定制需求还不够强(套装软件能满足)或者行业不愿做,并不能说明它做不了。
六、低代码不适合开发哪些类型的应用
对算法和复杂数据结构要求比较高的:我想不会有人想到用低代码平台去刷LeetCode题、打ACM比赛的吧。这里有个细微的地方是要区分是业务逻辑比较复杂还是算法逻辑比较复杂,业务逻辑复杂对低代码来说不是问题,算法逻辑复杂才是问题。那啥叫业务逻辑复杂呢,就是业务人员总之是说得清楚,或者是能理解的;啥叫算法逻辑复杂呢,就是业务人员只能给个目标,具体怎么实现是不管的,就算解释也是一脸闷逼听不懂的。 对界面要求特别高的:比如游戏或抖音、云音乐这样的社交娱乐型的应用。目前主流的低代码平台都不擅长做酷炫的界面(也有一些特定类型的低代码平台如App Onboard是面向游戏开发的,不在本文讨论范围之内)。 头部互联网级应用:头部互联网应用用户量巨大,为了优化性能有很多很多trick,前后台技术架构非常复杂,低代码平台的实现是比较标准的数据库 / 逻辑 / 界面三层架构,无法满足性能需求。注意这不是说所有互联网应用都不合适,只是指那些用户量特大的头部应用。 分析和智能化应用:分析类应用自然应该用更专业的BI工具,智能化应用也应该用更专业的机器学习平台等工具。 系统软件、科学计算等其他专业性很强的应用。这个不多说了,估计也没谁想用低代码来做,但多说一句,虽然这些系统的内核肯定不适合低代码开发,但界面可是很适合,我们轻舟低代码产品正是脱胎于云计算平台的界面开发。
说低代码适合“简单的工作流和表单流转的应用”:事实上专业的低代码并不见得特别适合这类应用,比如Gartner就说OutSystems这方面的支持还不太好。其实最适合这类应用的反而是那些“表单驱动”的产品,这些产品并非专业的低代码平台。专业的低代码平台搞这些也不是完全不行,但属于大炮打蚊子,性价比不高。 说低代码适合“生命周期短的应用”:事实上如果你用OutSystems这样“最专业”的低代码平台去做营销活动页这样“生命周期短的应用”,你肯定会欲哭无泪。为什么?因为营销活动页对界面的要求很高哎。 说低代码适合“创新型应用”:有篇文章按Gartner的方法把应用分成基础设施型(如 ERP)、差异化型(如 CRM)和创新型应用,说前两类应用低代码就别碰了,都是传统IT的菜,低代码就搞搞创新型应用,这个说法也不对。互联网App算典型的创新型应用吧,上面已经说过这个低代码搞不定。
七、低代码不是银弹,不要过度神化
开发工具只能解决软件研发的部分问题。
低代码能提升多少开发效率缺乏权威数据,不要有太高预期。
行业典型的项目制限制了低代码的价值。
小结
最后做个小结:
无代码和低代码不是一个层次的概念。低代码是以OutSystems、Mendix等产品为代表,主要面向专业开发的通用应用开发平台;无代码则是一个营销用语,用于形容很多种面向业务人员的工具,如应用搭建、在线表单、工作流等。不存在无代码的通用应用开发平台。无代码这个概念过于宽泛,未来很可能会慢慢淡出市场。 要判断一个低代码平台是否专业,可以重点看模型驱动、可视化开发、表达式语言、软件工程、开放集成和脚本语言等六个方面。对照这些标准,不难看出迄今为止应该说国内还很少有专业的低代码平台,虽然舆论甚是喧嚣。 业界关于低代码适用场景的观点大多数都是错的。比如业界很多人讲低代码搞不定复杂的企业级应用,但都毫无根据。从技术原理出发,低代码其实最适合做的就是企业应用,即便是CRM、ERP这样复杂的应用;业界认为低代码适合做“简单的工作流和表单流转的应用”、“生命周期短的应用”、“创新型应用”等观点也都是错的,这些应用很多恰恰不适合低代码。 低代码不适合做的应用是对算法、界面、性能、分析和智能化等专业性要求高的应用。 低代码对企业应用开发价值明显,但也不是银弹,不要过度神化。
对甲方来说,我认为CIO们应该从试点应用做起,通常来说要求自己的团队用低代码的阻力会很大,但可以要求乙方用低代码,降报价。
对乙方,我觉得短期很难卖平台,最好是和甲方谈个人力外包模式,避免项目制的僵化。业界说低代码是“高级外包”倒也没说错,虽然我觉得既然用的是低代码应该叫“低级外包”更合适😄。
最后的最后,我再次呼吁分析机构能够区分低代码和无代码,聚焦分析面向通用应用开发的低代码开发平台,促进这个行业的认知统一,产品的标准化,这样才能够推动行业发展。
无代码将死,低代码长存!
![](https://filescdn.proginn.com/067583953909daf0e866989f5ed07a2a/8ccb0fadd69d11a254dd3931ab8a8081.webp)