一直想写篇文章,聊一聊“低代码”这个话题。一方面,“低代码”这个概念确实非常火,其热度丝毫不亚于曾经的“中台”。有人说,2021年是属于“云原生”的时代,看起来我们每一年都在被技术的“娱乐圈”抛弃,明明连 Kubernetes 都还没有入门呢?人们已然在欢呼雀跃般地声称要抛弃 Docker 。这个世界有时就是如此地魔幻,明明我们生活在一个拥有大量基础设施的时代,我们不必再像前辈们“刀耕火种”一般地去开发软件,可我们的生存空间为什么就越来越狭窄了呢?拼多多事件过去没有多久,腾讯的阳光普照奖再次让“打工魂”觉醒,也许果真像大鱼海棠里设定的一样,人的记忆只有7秒。而另一方面,我想结合我最近开发“工作流”的感受,来吐槽下这个看起来美好的“低代码”。也许,对企业而言,引入“低代码”的确能减少研发成本,可博主并不认为,它会降低业务本身的复杂性,如果所有声称“低代码”或者“无代码”的项目,最终依然需要研发人员来作为收场。对此,我想说,对不起,这不是我想要的“低代码”。

低代码发展现状

或许,一个人成熟的标志就是,在面对一个未知的事物的时候,决不会不由分说地一通吐槽,就像一个人在职场上,你不能永远都只是学会抱怨,相对于抱怨,人们更希望听到的是解决方案。所以,一个人的成长,本质上就是不断学会为自己、为别人找解决方案的过程,前者是为了认识自我,而后者是为了交换资源。所以,在听我吐槽“低代码”前,不妨先一起来看看低代码的发展现状。

低代码产品发展现状
低代码产品发展现状

国外趋势

有人认为,“低代码”的兴起源于钉钉的低代码应用 易搭 的落地。诚然,巨头企业的每一个动向都引领着整个行业的风潮,可低代码这个概念最早要追溯到1980年。彼时,IBM 的快速应用程序开发工具(RAD)被冠以新的名字——低代码,这是低代码这个概念首次面向大众,此后的40年里,国外诞生了诸如 OutsystemMendixZoho Creator 等等的产品,整体发展相对缓慢。直到2015年以后,AWS、Google、Microsoft 和 Oracle 等巨头开始入局低代码领域。2018年,西门子更是宣布以 6 亿欧元收购低代码应用开发领域的领导者 Mendix 、快速应用开发的低代码平台 Outsystem 获得 3.6 亿美金的投资,低代码平台市场开始火爆起来,我们所熟悉的 Power Platform,其实就是微软的低代码开发平台,低代码领域通常都需要大量的积累和研发,需要有10到20年左右的技术沉淀。

国内风云

国内的低代码领域,相比国外发展起步较晚,可依然涌现出像牛刀APICloudiVX搭搭云、氚云、简道云、云表、宜搭云等等产品。从整体上而言,这类这类产品基本上都提供了可视化搭建环境,都声称无需编码即可完成业务系统的搭建。其实,从一名程序员的初心出发,我们所做的一切努力都是为了以后不写代码。经常有人问,怎么样可以做到零缺陷、零 Bug ,其实不写代码就好啦!我们并不担心低代码让我们失业,相反地,如果低代码可以消化掉 30% 的垃圾项目,那么,我们将会有更多的时间去做些有意义的事情,而不是在一个“劣币驱逐良币”的市场里,靠着 996 来争个你死我活。而从低代码的商业价值角度来看,SalesforceAppianJoget 这三家公司均已上市,MendixOutsystem 更是估值 10 亿美元以上的独角兽公司,这正是巨头们入局低代码的原因所在。

低代码领域,目前关注的重点主要集中在:表单生成和处理工作流生成和管理办公协作人力资源客户关系ERP 等企业应用上,就如同 SAP金蝶SCM 等企业软件一样,每一个软件都曾声称能帮助企业解决某一类问题,低代码领域同样遵循“二八原则”,即 80% 的场景,通过定义的方法论、方式、工具集能够实现;而剩下的 20% 的场景或许实现不了,需要使用者通过扩展的方式来自行解决。譬如,针对大多数企业都存在的 CRUD 的需求,通过在线的 Excel 表格来实现基于表的业务驱动。例如 SeaTable 就是这类主打协同工作的产品;针对大多数企业都存在的审批类的需求,则可以通过可视化的工作流设计系统来完成。例如 葡萄城SpreadJS活字格 ,同样可以视为低代码平台,甚至早期的 .NET 开发者被人“黑”只会拖控件,这难道不是广义上的低代码吗?

低代码产品形态

搞清楚整个低代码的发展现状以后,那么,整个低代码领域主要的产品形态有哪些呢?了解其主要的产品形态,对于我们形成低代码的直观印象非常有帮助。在我看来,主要分为四类:

  • 表单生成类:以 宜搭云JNPF 为代表,主张通过可视化的设计器来完成页面布局、编排、设计,即所谓的“所见即所得”,类似的还有 iVX
  • 工作流生成类:以 Mendix 和 Outsystems 为代表,提供组件式的服务,通过编排工作流来实现特定的业务,即通过流程图的方式来实现业务逻辑部分,不同的节点代表不同的功能,不同的线条代表不同的分支。
  • 协同工作类:以 SeaTable 为代表,基于表的业务驱动开发平台,可以以不同的维度管理数据、对数据可视化、共享协作等等,同时具备自动化规则、脚本运行等能力。
  • 服务聚合类:以 APICloud 为代表,基于API聚合的组件市场工具,通过流程管理工具,可以管理整个应用的开发周期,从产品、设计开始,到研发测试和运营。

所以,整体而言,低代码产品的核心是表单引擎流程引擎(BPM),外围支撑是BI引擎*协同工作服务聚合等等,目前,市面上主流的低代码产品,表单引擎和流程引擎(BPM)基本是标配,所以,严格地说起来,上面的分类并不严谨,因为基本上都是混合式的产品形态。下面是部分低代码产品的截图:

某“低代码”二维码应用
某“低代码”二维码应用
某“低代码”人力资源管理系统
某“低代码”人力资源管理系统
某“低代码”可视化搭建系统
某“低代码”可视化搭建系统

低代码研发痛点

相信大家都知道了,接下来的内容是本文真正的重点。为什么要这样说呢?这主要和博主自身的工作有关系,简单来说,公司需要一个想象中的可视化设计器,业务人员只需要通过拖拽就可以完成业务逻辑的编排,而开发人员则需要负责对外输出组件供业务人员使用。这听起来特别像我们刚刚讨论的第二种产品形态对不对?听起来非常美好对不对?我承认这个想法真的符合潮流、非常的“低代码”。所以,我们前期采用了微软的 Windows Workflow Foundation 框架,使用以后的效果大概是下面这个样子:

Windows Workflow Foundation 设计器
Windows Workflow Foundation 设计器

多人协作不便

那么,我们在这个过程中到底遇到了哪些问题呢?首先,这种可视化编辑的场景,遇到的第一个问题就是多人协作,如果你使用过腾讯文档、钉钉文档这类在线文档类产品,你应该能领悟到我说的这个点。微软的这个框架是采用XMAL这种格式来储存数据的,虽然理论上可以通过 Git 实现多人协作,实际维护起来表示非常地麻烦,所以,我们最终由单人去维护这些工作流。那么,更广义上的低代码又该如何解决这个问题呢?流程图这种东西,就是一种看起来非常清晰,改起来非常麻烦的东西,就像一条锁链一样,你要不停地断开和接上。

孱弱的表达能力

其次,是流程图这种表现方式的“表达”问题,就像你如果需要在SQL里表示循环要用到游标一样,这类工作流都无法表达程序三个结构中的循环,更不用说表达力孱弱的表达式啦,所以,这就造成一个非常尴尬的问题,你在流程图里写不了太复杂的表达式,一旦业务人员写不出来,就需要开发人员去写辅助性质的代码,类似正则字符串插值字符串处理、格式化等等的函数或者API非常缺乏。当然,我最无法忍受的,就是组件与组件间传值的方式,你除了返回JSON和写表再没有其它方式,更何况这个JSON返回给某个组件了,人家还未必能直接解析直接使用呢?因为编辑器无法绑定这种复杂的数据结构。

混乱的变量和参数

接下来,我最想吐槽的是,关于全局变量参数的问题,在流程图中你经常需要各个分支的标志位(Flag)或者是临时变量,然后你就看到了那种“变量满天飞”的混乱局面,简直像极了你刚开始写的代码,你需要顺着每个线条,逐个点开每个组件的属性面板,查看它都使用了哪些参数或者变量,至此,你终于明白了它的数据是如何流动的。从前,乡愁是成千上万行的代码;现在,乡愁是剪不断理还乱的“蜘蛛网”。多年前,我对虚幻引擎(Unreal)的蓝图功能有多么憧憬;多年后,我对这种基于流程引擎的低代码就有多排斥。尤其是,当我需要复用某一段逻辑的时候,我只能小心翼翼地选中节点和线条,然后再拷贝过去。

动态计算/事件顺序/黑盒子

最后,我参考了一位被 Power Apps 所折磨的朋友的意见,除了上面提到的这些问题, 属性面板或者公式无法使用动态计算的值,类似Vue 里面的计算属性,从实际使用的体验来看,这类以流程引擎和表单引擎为主要卖点的低代码工具,其实都会存在这样的问题,而面对这种问题,一般只能通过trick的手段来解决。同样地,Power Apps 事件顺序的不确定问题,因为低代码实际上是框架提供了某种机制,可以帮你完成某个事情,所以,低代码内部对于使用者来说,完全就是一个黑盒子,譬如 Power Apps 在无网络的环境下使用会卡顿,调试起来非常不便等等。

本文小结

坦白来讲,这篇博客实在没什么“技术含量”,无非是按照一个月前的计划在整理内容。我对“低代码”持一种中立的态度,作为程序员,我是希望有这样的技术来简化流程,可以让研发人员从枯燥的“增删改查”中解放出来,留出时间去做更多有意义、有价值的事情。当我了解了低代码和零代码的差异以后,我突然明白,我需要的其实是零代码,因为我希望那帮业务人员能自己搞定,这样就不用再来烦我,可经历这段时间的“低代码”,我清醒地认识到,这个想法根本不现实。一来业务人员并不像他们想象的那样,除了不会写代码以外无所不能;二来业务的复杂性满足守恒定律,它永远不会消失,只会从一种形式变成另一种形式也许,低代码真的能帮企业省不少钱;也许,企业最喜欢做的事情,就是花点小钱招人外包做这种事情。但我依然想告诫开发者们,不要去追逐这些看起来美好的东西,对企业来说,它今天使用 A 技术,明天使用 B 技术,完全无关紧要。可对于个人而言,这个选择显得非常重要。看一看曾经的 SAP 咨询顾问就知道了,如果有一天 SAP 都倒闭了,你掌握着这些只有在 SAP 上能发挥作用的技术有什么用呢?对技术人员来说,学习通用型的知识和技能,永远比把鸡蛋放在一个篮子里要更保险