背景介绍近年来，前端社区关于低代码（LowCode）和无代码（NoCode）的讨论越来越火。应用的开发和上线以代码的形式完成，无需编写代码，通过配置即可完成整个应用的开发。目前群内已经有很多低代码平台，如iceluna、亿达、乐高、云峰蝶等，通用的无代码平台还处于探索阶段。低代码与无代码首先，不管是低代码还是无代码，都是针对特定的场景或者细分，比如运营活动页面、中后台表单、表格页面等，因为只有在这些场景下，前端交互比较收敛，才能沉淀足够多的组件素材，从而可以通过可视化的方式直接拖拽组件搭建页面。目前，我的团队正在研究营销领域的中后台和前端解决方案。一般来说，中后台解决方案的核心目标是提高效率。效率提升包括两个方面。一是提高研发人员的效率，二是提高用户的效率。效率提升的核心是生产。关系转变，从前端开发到后端、视觉、产品开发，降低前端研发门槛，提??高生产效率。效率提升不是解决20%的个性化增量需求，而是通过涉及“非前端”解决80%的通用需求。中后台的效率提升路径大多是ProCode->LowCode->NoCode。从表面上看，ProCode->LowCode->NoCode似乎只有很小的差别，好像只是代码量的问题，但是整个过程已经从量变到质变了。ProCode和LowCode主要针对需要前端编程技能的人，而NoCode则意味着“非前端”也可以参与前端页面的建设。这并不意味着根本不需要代码，因为今天什么才算是“代码”？”其实更难定义。比如用户写了一个配置文件，这个文件是json格式的，能不能算作“代码”？所以NoCode并不代表没有代码，而是降低了用户的学习门槛和学习成本，普通用户无需刻苦学习，就可以做到以前只能通过编码才能实现的事情。iceluna低代码平台痛点作为群内优秀的低代码平台，iceluna主要解决快速构建中后台页面的场景。经过几年的摸索，基本可以实现页面UI的可视化构建，但是业务逻辑还需要手工操作。编码实现。这对于非前端开发者来说入门还是比较高的。下图是最近对ice??luna用户（前端、后端和测试）的一次调查分析。可以看出，逻辑代码和数据绑定的学习成本也是用户在问卷中提及最多的。因此，在本财年，我们尝试用可视化的逻辑编排来解决逻辑相关的问题，解决low-code最后需要编码的部分，实现无代码的研发模式，从而进一步减少学习和学习。用户使用门槛。可视化逻辑排列首先我们用一个逻辑排列的例子，看看一段代码排列后的样子：如上图所示，原本晦涩难懂的代码逻辑通过流程图的形式呈现出来，表达后，产品的逻辑变得非常直观。可读性和可维护性也变得非常高。接手别人的项目时再也不用担心注释不规范、文档不完整。逻辑排列生成的逻辑图是一个天然的产品文档。从逻辑节点的抽象可以看出，要形成这样的逻辑图，本质上需要将不同的逻辑节点进行组合和连接，而真正的逻辑是由封装在节点中的功能来完成的。那么这里有两个问题。首先是如何抽象逻辑节点。抽象出来的逻辑节点能否复用，直接决定了用户编排的成本。如果需要不断定制个性化的逻辑节点，可能会失去编排的意义。;其次，逻辑节点的粒度也很关键。如果封装的逻辑粒度太大，大到一个功能服务，那么就可能变成业务流程安排；如果粒度太小，小到一个表达式Level，那么对于有编程基础的同学来说，直接写代码可能效率更高。通过梳理中后台营销领域的一些业务代码，发现大部分中后台页面都是以表单、列表、详情为主，90%的业务逻辑基本围绕表单展开（验证、取值、赋值、提交）、对话框（显示、提示）、发送请求、消息提示、数据处理、路由跳转、条件判断等，比较收敛。同时，iceluna作为群内优秀的低代码构建平台，在上层封装了很多非常好用的API，屏蔽了大部分前端的语法差异，比如状态赋值，页面刷新，接口调用，以及一些常用的工具函数（时间处理）等，为逻辑节点的抽象提供了极大的方便。通过分析和分类，最终沉淀出10个左右的逻辑节点，如下图所示。同时，每个逻辑节点本质上对应一个执行函数，接收一个参数作为输入参数，返回一个参数作为输出参数。编排协议既然是可视化编排，自然少不了编排协议。为了避免重复建设，最大限度的复用组内已有的编排方案，最终计划采用LF通用可视化逻辑编排协议，在iceluna中实现逻辑编排。技术架构图技术难点自动化布局从我们研究之初，我们发现大部分编排产品都是用户自己通过拖拽、连接等操作完成的，但是通过前面分析逻辑代码，如果我们异步回调使用async/await将操作转化为同步的写法，所以大部分逻辑代码可以看做是串行执行的过程，偶尔会叠加一些if/else分支判断，也很符合人们常用的思维模式非常直观易懂。所以从布局上来说，就是把不同的逻辑节点和分支判断节点串联起来。布局不需要太灵活，连线操作也是多余的，所以我们将所有的拖拽连线改成添加节点，然后自动连线。使用这种自动布局方式将大大简化用户的操作。用户只需要关注核心业务逻辑流程，按顺序添加节点即可，但这也带来了一个问题，因为分支类型的节点会产生两个分支流程，如果遇到嵌套的分支，需要自动平移位置上层分支的横坐标向右移动一个单位，否则上下层不同分支上的节点位置可能重叠。为此，我设计了一个自动布局算法，最终效果图如下：算法过程比较简单，采用DFS深度优先遍历算法，详细过程在此不再赘述。代码和schema互转逻辑图整理好后，接下来的问题就是如何保证整理后的逻辑正确运行，产生和源码一样的效果。一开始讨论了两种解决方案。第一种方案，将整个逻辑看成一个事件流，按照之前设计好的逻辑来编排schema，通过事件注册和监听完成逻辑节点的上下游连接，最后设计一套事件执行器，触发事件在顺序。这种方式实现起来比较简单，但是对原有开发流程的侵入性较大。因为原来保存事件函数的地方会换成逻辑schema，负责codereview的前端同学看到的将不再是codediff，而是schemadiff，这无疑会大大增加CR的风险。因此，经过一番讨论，我们决定采用第二种方案，将逻辑排列好的schema自动转换成代码，同时生成的代码也要自动转换回schema。基于模式转换代码相对容易，因为每个逻辑节点本身映射一段功能，将代码转换回模式稍微复杂一些。这里Babel主要是用来解析代码先得到抽象语法树AST，然后遍历AST中类型语句的节点，最后通过正则匹配找到对应的逻辑节点，串联起来。下图是生成的代码示例：可以看出，通过schema生成的代码与源代码还是有一些区别，具有一些逻辑排列的特点，但是从代码上看更加具有可读性和直观性。逻辑流程图的逆向推导在一定程度上降低了codereview的成本。整个AST解析过程如下：断点调试不可避免地需要调试写业务逻辑的函数，这对于有编程功底的同学来说是再自然不过的事情，但是当逻辑变得可视化排列时，如何让这些“非前端”用户还可以通过调试方便地定位错误就变得尤为关键。调试其实就是用户安排好后进行逻辑仿真的过程。因此，我们对逻辑节点的每一个环节都有嵌入点，用户可以在仿真运行过程中查看每一个节点。数据状态、上下文参数、错误类型等，根据逻辑流程图的状态（绿色表示执行成功，红色表示执行失败），也可以很快定位到问题，如图下图：调试功能还在起步阶段，后期会继续迭代优化，比如在调试时加入单步执行功能，像浏览器的单步调试工具一样进行断点。总结展望总结目前，可视化逻辑编排已正式上线集团内的iceluna低代码构建平台，并正式应用于营销工具业务。从低代码到无代码研发模式的升级还处于探索阶段，过程中难免会遇到很多问题，但也算是至关重要的一步，值得期待。前面说了，从ProCode->LowCode->NoCode，通过降低研发门槛，让非技术人员参与应用开发，可以大大提高生产效率，但是理想很丰满，现实也是很瘦。NoCode搭建平台我觉得目前只能应用在比较垂直的场景，而且因为还可以写代码的转义机制不像LowCode，所以NoCode方式可能只能完成一个70分左右的产品。但是换个角度来看，如果一个非技术人员能够以非常低的门槛完成一个70分左右（最低可用产品MVP）的产品，并且可以直接推向市场试错，如果验证可行，则通过转换为LowCode或ProCode继续迭代优化。我觉得光这一点就很有价值，是推动商业创新的核心动力。因此，我认为未来产品开发的节奏可能是从NoCode->LowCode->ProCode。每个进程都必须有对应的解决方案，并且能够相互通信。只有这样，才能在竞争日益激烈的市场环境中更具竞争力。良好的生存。
