一直想写篇文章，聊一聊“低代码”这个话题。一方面，“低代码”这个概念确实非常火，其热度丝毫不亚于曾经的“中台”。有人说，2021 年是属于“云原生”的时代，看起来我们每一年都在被技术的“娱乐圈”抛弃，明明连 Kubernetes 都还没有入门呢？人们已然在欢呼雀跃般地声称要抛弃 Docker 。这个世界有时就是如此地魔幻，明明我们生活在一个拥有大量基础设施的时代，我们不必再像前辈们“刀耕火种”一般地去开发软件，可我们的生存空间为什么就越来越狭窄了呢？拼多多事件过去没有多久，腾讯的阳光普照奖再次让“打工魂”觉醒，也许果真像大鱼海棠里设定的一样，人的记忆只有 7 秒。而另一方面，我想结合我最近开发“工作流”的感受，来吐槽下这个看起来美好的“低代码”。也许，对企业而言，引入“低代码”的确能减少研发成本，可博主并不认为，它会降低业务本身的复杂性，如果所有声称“低代码”或者“无代码”的项目，最终依然需要研发人员来作为收场。对此，我想说，对不起，这不是我想要的“低代码”。
低代码发展现状
或许，一个人成熟的标志就是，在面对一个未知的事物的时候，决不会不由分说地一通吐槽，就像一个人在职场上，你不能永远都只是学会抱怨，相对于抱怨，人们更希望听到的是解决方案。所以，一个人的成长，本质上就是不断学会为自己、为别人找解决方案的过程，前者是为了认识自我，而后者是为了交换资源。所以，在听我吐槽“低代码”前，不妨先一起来看看低代码的发展现状。
国外趋势
有人认为，“低代码”的兴起源于钉钉的低代码应用 易搭 的落地。诚然，巨头企业的每一个动向都引领着整个行业的风潮，可低代码这个概念最早要追溯到 1980 年。彼时，IBM 的快速应用程序开发工具(RAD)被冠以新的名字——低代码，这是低代码这个概念首次面向大众，此后的 40 年里，国外诞生了诸如 Outsystem 、Mendix 、 Zoho Creator 等等的产品，整体发展相对缓慢。直到 2015 年以后，AWS、Google、Microsoft 和 Oracle 等巨头开始入局低代码领域。2018 年，西门子更是宣布以 6 亿欧元收购低代码应用开发领域的领导者 Mendix 、快速应用开发的低代码平台 Outsystem 获得 3.6 亿美金的投资，低代码平台市场开始火爆起来，我们所熟悉的 Power Platform，其实就是微软的低代码开发平台，低代码领域通常都需要大量的积累和研发，需要有 10 到 20 年左右的技术沉淀。
国内风云
国内的低代码领域，相比国外发展起步较晚，可依然涌现出像牛刀、APICloud、iVX、搭搭云、氚云、简道云、云表、宜搭云等等产品。从整体上而言，这类这类产品基本上都提供了可视化搭建环境，都声称无需编码即可完成业务系统的搭建。其实，从一名程序员的初心出发，我们所做的一切努力都是为了以后不写代码。经常有人问，怎么样可以做到零缺陷、零 Bug ，其实不写代码就好啦！我们并不担心低代码让我们失业，相反地，如果低代码可以消化掉 30% 的垃圾项目，那么，我们将会有更多的时间去做些有意义的事情，而不是在一个“劣币驱逐良币”的市场里，靠着 996 来争个你死我活。而从低代码的商业价值角度来看，Salesforce、Appian、Joget 这三家公司均已上市，Mendix 和 Outsystem 更是估值 10 亿美元以上的独角兽公司，这正是巨头们入局低代码的原因所在。
低代码领域，目前关注的重点主要集中在：表单生成和处理、工作流生成和管理、办公协作、人力资源、客户关系、ERP 等企业应用上，就如同 SAP 、金蝶、 SCM 等企业软件一样，每一个软件都曾声称能帮助企业解决某一类问题，低代码领域同样遵循“二八原则”，即 80% 的场景，通过定义的方法论、方式、工具集能够实现；而剩下的 20% 的场景或许实现不了，需要使用者通过扩展的方式来自行解决。譬如，针对大多数企业都存在的 CRUD 的需求，通过在线的 Excel 表格来实现基于表的业务驱动。例如 SeaTable 就是这类主打协同工作的产品；针对大多数企业都存在的审批类的需求，则可以通过可视化的工作流设计系统来完成。例如 葡萄城 的 SpreadJS 和 活字格 ，同样可以视为低代码平台，甚至早期的 .NET 开发者被人“黑”只会拖控件，这难道不是广义上的低代码吗？
低代码产品形态
搞清楚整个低代码的发展现状以后，那么，整个低代码领域主要的产品形态有哪些呢？了解其主要的产品形态，对于我们形成低代码的直观印象非常有帮助。在我看来，主要分为四类：
- 表单生成类：以 宜搭云 和 JNPF 为代表，主张通过可视化的设计器来完成页面布局、编排、设计，即所谓的“所见即所得”，类似的还有 iVX。
- 工作流生成类：以 Mendix 和 Outsystems 为代表，提供组件式的服务，通过编排工作流来实现特定的业务，即通过流程图的方式来实现业务逻辑部分，不同的节点代表不同的功能，不同的线条代表不同的分支。
- 协同工作类：以 SeaTable 为代表，基于表的业务驱动开发平台，可以以不同的维度管理数据、对数据可视化、共享协作等等，同时具备自动化规则、脚本运行等能力。
- 服务聚合类：以 APICloud 为代表，基于 API 聚合的组件市场工具，通过流程管理工具，可以管理整个应用的开发周期，从产品、设计开始，到研发测试和运营。
所以，整体而言，低代码产品的核心是表单引擎 和 流程引擎(BPM)，外围支撑是BI 引擎、*协同工作、服务聚合等等，目前，市面上主流的低代码产品，表单引擎和流程引擎(BPM)基本是标配，所以，严格地说起来，上面的分类并不严谨，因为基本上都是混合式的产品形态。下面是部分低代码产品的截图：
低代码研发痛点
相信大家都知道了，接下来的内容是本文真正的重点。为什么要这样说呢？这主要和博主自身的工作有关系，简单来说，公司需要一个想象中的可视化设计器，业务人员只需要通过拖拽就可以完成业务逻辑的编排，而开发人员则需要负责对外输出组件供业务人员使用。这听起来特别像我们刚刚讨论的第二种产品形态对不对？听起来非常美好对不对？我承认这个想法真的符合潮流、非常的“低代码”。所以，我们前期采用了微软的 Windows Workflow Foundation 框架，使用以后的效果大概是下面这个样子：
多人协作不便
那么，我们在这个过程中到底遇到了哪些问题呢？首先，这种可视化编辑的场景，遇到的第一个问题就是多人协作，如果你使用过腾讯文档、钉钉文档这类在线文档类产品，你应该能领悟到我说的这个点。微软的这个框架是采用XMAL这种格式来储存数据的，虽然理论上可以通过 Git 实现多人协作，实际维护起来表示非常地麻烦，所以，我们最终由单人去维护这些工作流。那么，更广义上的低代码又该如何解决这个问题呢？流程图这种东西，就是一种看起来非常清晰，改起来非常麻烦的东西，就像一条锁链一样，你要不停地断开和接上。
孱弱的表达能力
其次，是流程图这种表现方式的“表达”问题，就像你如果需要在SQL里表示循环要用到游标一样，这类工作流都无法表达程序三个结构中的循环，更不用说表达力孱弱的表达式啦，所以，这就造成一个非常尴尬的问题，你在流程图里写不了太复杂的表达式，一旦业务人员写不出来，就需要开发人员去写辅助性质的代码，类似正则、字符串插值、字符串处理、格式化等等的函数或者 API 非常缺乏。当然，我最无法忍受的，就是组件与组件间传值的方式，你除了返回 JSON 和写表再没有其它方式，更何况这个 JSON 返回给某个组件了，人家还未必能直接解析直接使用呢？因为编辑器无法绑定这种复杂的数据结构。
混乱的变量和参数
接下来，我最想吐槽的是，关于全局变量和参数的问题，在流程图中你经常需要各个分支的标志位(Flag)或者是临时变量，然后你就看到了那种“变量满天飞”的混乱局面，简直像极了你刚开始写的代码，你需要顺着每个线条，逐个点开每个组件的属性面板，查看它都使用了哪些参数或者变量，至此，你终于明白了它的数据是如何流动的。从前，乡愁是成千上万行的代码；现在，乡愁是剪不断理还乱的“蜘蛛网”。多年前，我对虚幻引擎(Unreal)的蓝图功能有多么憧憬；多年后，我对这种基于流程引擎的低代码就有多排斥。尤其是，当我需要复用某一段逻辑的时候，我只能小心翼翼地选中节点和线条，然后再拷贝过去。
动态计算/事件顺序/黑盒子
最后，我参考了一位被 Power Apps 所折磨的朋友的意见，除了上面提到的这些问题， 属性面板或者公式无法使用动态计算的值，类似Vue 里面的计算属性，从实际使用的体验来看，这类以流程引擎和表单引擎为主要卖点的低代码工具，其实都会存在这样的问题，而面对这种问题，一般只能通过trick的手段来解决。同样地，Power Apps 事件顺序的不确定问题，因为低代码实际上是框架提供了某种机制，可以帮你完成某个事情，所以，低代码内部对于使用者来说，完全就是一个黑盒子，譬如 Power Apps 在无网络的环境下使用会卡顿，调试起来非常不便等等。
本文小结
坦白来讲，这篇博客实在没什么“技术含量”，无非是按照一个月前的计划在整理内容。我对“低代码”持一种中立的态度，作为程序员，我是希望有这样的技术来简化流程，可以让研发人员从枯燥的“增删改查”中解放出来，留出时间去做更多有意义、有价值的事情。当我了解了低代码和零代码的差异以后，我突然明白，我需要的其实是零代码，因为我希望那帮业务人员能自己搞定，这样就不用再来烦我，可经历这段时间的“低代码”，我清醒地认识到，这个想法根本不现实。一来业务人员并不像他们想象的那样，除了不会写代码以外无所不能；二来业务的复杂性满足守恒定律，它永远不会消失，只会从一种形式变成另一种形式。也许，低代码真的能帮企业省不少钱；也许，企业最喜欢做的事情，就是花点小钱招人外包做这种事情。但我依然想告诫开发者们，不要去追逐这些看起来美好的东西，对企业来说，它今天使用 A 技术，明天使用 B 技术，完全无关紧要。可对于个人而言，这个选择显得非常重要。看一看曾经的 SAP 咨询顾问就知道了，如果有一天 SAP 都倒闭了，你掌握着这些只有在 SAP 上能发挥作用的技术有什么用呢？对技术人员来说，学习通用型的知识和技能，永远比把鸡蛋放在一个篮子里要更保险。