Low Code

去年 3 月，上了一个 M 项目，当时客户想要做一个工作流平台给 People 团队来支撑员工入离职·请假等流程。客户前期在技术选型方面和以往的项目都不太一样，前端是一个成本很高的表单引擎，后端是一个业务流。 前端表单引擎可以通过定义 yaml 文件快速生成一个员工表单页面，甚至这个页面会根据登录的员工预填其个人信息，但这个引擎对开发非常不友好，生成出来的表单，想做一点修改都非常困难，比如记得当时有一个文字对齐的 bug，和表单引擎的开发团队聊完之后发现完全无能为力。表单在收集了员工填写的信息之后，会发给后端，后端整理一下数据然后触发一个业务流（当时我们调研了 Microsoft flow, AWS stepFunction 等工具后选了 Step Function), 业务流会根据表单内容相应地给员工 manager 和 HR 等相关人员在相应时间结点发邮件，创建工单。

当时感觉这不就是一个加了流程的高级版金数据么，但实际很不幸，当时我们被那个表单引擎折磨的不行，以我们做前端的经验，一个几个字段的小表单，手写也就一两天的工作量，为了部署和使用那个表单引擎，我们整整花了两个多月，当时很不理解为什么客户不计代价坚持使用它。

带着疑问我下了项目来到了 9 月，上了 C 项目。在 C 项目上，接触到了一个新词叫“低代码”。这下我才恍然明白 M 项目就是为了打通一个 People 专用的“低代码平台”，它的好处是当这个平台搭起之后，People 团队如果想加新的流程，只需前端用 yaml 来定义表单，后端用 json 来定义一个新的 StepFunction 流程就可以快速上线了，他们把业务解构到非开发人员也看的明白的 yaml 和 json 文件中，当他们流程变更，他们也可以自己快速做修改。

C 项目是去构建一个通用的低代码平台，刚上项目准备大干一场的时候，就看到 CTO 8x 的全网在推的视频《低代码是行业毒瘤》，😢, 想着“既来之，则安之”，不如好好做一下，体会一下是不是毒瘤。做了半年它是我做过的最 tough 的一个项目，业务非常烧脑，思维常常在编辑态，运行态之间来回切换。常常和客户反复讨论实现方案，开始对毒瘤有一些理解。

我们可以按我们开发软件的过程来思考低代码，实际上我们在设计低代码的过程也是不停地反来想我们是怎么写代码，模拟我们写代码需要的所有元素。

C 项目的实现整体上来讲可以这样来抽象：

1. 编辑态：让程序设计者通过拖拉拽，生成一个巨大的 Json 文件。相当于我们在用 IDE 写代码，只不过我们的源代码是更表意更精炼的高级程序语言，用低代码做出的源代码是 JSON 文件。IDE 或 LSP 提供高亮，语法补全，lint 提示。编辑态的低代码平台也同样需要提供友好的验证和提示。
2. 运行态：相当于 JSON 文件的解释器。为了让之前制作的 JSON“源代码”运行起来。而这个低代码平台充当了一个完整的云平台功能 ，不仅提供代码存储，版本管理，代码运行，运维支持。

设计一套完整的低代码平台相当于在基于 json 设计一个完整的编程语言，而实现一套完整的低代码平台更麻烦，需要为这个理论的语言提供一个图形化的 IDE，为平台上制作的程序提供 json 源代码管理，为 json 源代码提供解释器，这个解释器要既要能转化成前端的代码又要能转化成后端代码，程序运行起来之后还要为它们提供完善的运维支持，日志管理。

两个度： 傻瓜度： UI > DSL > general language what you can do: UI < DSL << general language

正面的一面：

1. 事实上现在市面上大部分低代码产品都在针对特定的场景做实现，比如 M 项目想做的针对企业员工表单业务。这现当于通过牺牲图灵完备性来降低复杂度。
2. 低代码平台无疑会降低应用的开发成本。
3. 低代码平台所能实现的程序有限，在低代码平台上无法再搭建另一个低代码平台，实现一套完全完备的通用低代码平台只是一个美丽的谎言，好像发明永动机一样，仿佛看到希望，却永远无法实现，我们在低代码平台设计时常常感觉到受制要做妥协，是带着镣铐在跳舞。

负面的一面：

1. 与其担心低代码会让程序员失业，还不如看看 Github Copilot…..