无代码解决方案：如何完全实现无代码化研发模式

近年来，关于低代码（LowCode）和无代码（NoCode）的讨论在前端社区内愈来愈火，简单的说低代码就是经过编写少许代码的方式完成应用的开发及上线，而无代码则更进一步，不须要编写代码经过配置的方式便可完成整个应用的开发。目前集团内部的低代码平台已经有不少，好比iceluna，宜搭，乐高，云凤蝶等等，而通用的无代码搭建平台还处在探索阶段。

低代码和无代码

首先无论是低代码仍是无代码，都是针对特定场景或者细分领域的，好比运营的活动页，中后台的表单，表格页面等，由于只有在这些场景下，前端交互相对收敛，可以沉淀出足够多的组件物料，从而经过可视化的方式拖拽组件就可以直接搭建出页面。

目前我所在的团队正在研究面向营销域的中后台前端解决方案。一般来讲，中后台解决方案的核心目标是提效，提效包括两个方面，一方面是对研发人员的提效，另外一方面是对用户的提效，提效的核心抓手在于生产关系的变动，由前端开发向后端，视觉，产品各方面参与发展，从而下降前端研发的门槛，提升生产效率。提效解决的不是20%的个性化增量需求，而是解决让“非前端”参与进来，解决80%的通用需求。中后台的提效路径大部分走的都是ProCode->LowCode->NoCode方式。

表面上看，从ProCode->LowCode->NoCode看起来好像只有很小的差异，好像只有代码量多少的问题，但整个过程已经从量变发生了质变。ProCode和LowCode主要面向的仍是一些须要有前端编程能力的人，而NoCode则表明“非前端”也可以参与的前端的页面搭建中来，这里面不是说彻底不须要代码，由于今天哪些算“代码”其实比较难界定，好比用户编写一个配置文件，这个文件是json格式的，那到底能不能算“代码”？因此，NoCode的意思不是说没有代码，而是说在于用户学习门槛和学习成本的下降，普通用户不须要通过艰难的学习就能够作到之前程序要编码才能实现的事情。

iceluna低代码平台的痛点问题

iceluna做为集团内优秀的低代码搭建平台，主要解决中后台页面快速搭建的场景，通过几年的探索，基本可以实现页面UI的可视化搭建，可是针对业务逻辑仍是须要手动编码来实现。这对非前端开发人员的上手门槛仍是比较高的。下面这张图是最近针对iceluna的用户（前端，后端和测试）作的一个调研分析，能够看到逻辑代码和数据绑定的学习成本也是用户在问卷中提的最多的。

所以在这个财年，咱们尝试去用可视化逻辑编排的方式解决逻辑相关的问题，解决低代码中最后一点须要编码的部分，实现无代码化的研发模式，从而进一步下降用户的学习和使用门槛。

可视化逻辑编排

首先咱们来经过一个逻辑编排的示例来看一下若是一段代码经过编排的方式呈现出来以后会带来怎么样的体感：

如上图所示，本来晦涩难懂的代码逻辑经过流程图的形式表达出来之后，产品的逻辑变得很是直观。可读性和可维护性也变得很是高。不再用担忧在接手其余人的项目时，注释不规范，文档不全的问题，逻辑编排生成的逻辑图谱就是自然的产品文档。

逻辑节点抽象

能够看出，要造成这样的逻辑图谱，本质上就是须要对不一样逻辑节点进行组合和串联，真正的逻辑由封装在节点中的函数完成。那么这里就产生了两个问题，首先是如何抽象逻辑节点，抽象出的逻辑节点能不能被复用直接决定了用户编排的成本，若是须要不断的定制个性化逻辑节点可能就失去了编排的意义；其次是逻辑节点的的颗粒度大小也很是关键，若是封装的逻辑颗粒度太大，大到一个功能服务，那么可能就变成了业务流程编排；若是颗粒度过小，小到一个表达式级别，那么对于有编程基础的同窗来讲，可能直接写代码效率反而更高。

经过对中后台营销域的部分业务代码进行梳理，发现中后台的页面大都是以表单、列表，详情为主，而其中90%的业务逻辑基本上都围绕在表单(校验，取值，赋值，提交)，对话框（显隐、提示），发送请求，消息提示，数据处理，路由跳转，条件判断等，相对比较收敛。同时iceluna做为集团内优秀的低代码搭建平台，在上层封装了不少很是好用的api，屏蔽了大部分前端语法层面的差别，好比状态赋值，页面刷新，接口调用，一些经常使用的工具函数（时间处理）等，为逻辑节点的抽象提供了极大的便利性。

经过分析归类，最后沉淀了10个左右的逻辑节点，以下图所示，同时每个逻辑节点最终本质上都是对应一段执行函数，并接收一个参数做为入参，返回一个参数做为出参。

编排协议

因为是可视化编排，天然也避免不了编排的协议，为了不重复建设最大程度的复用集团内已有的编排方案，最终计划采用LF通用可视化逻辑编排的协议来实现iceluna中的逻辑编排。

技术架构图

技术难点

自动化布局

从一开始调研咱们就发现大部分的编排产品，都是让用户本身进行拖拽，连线等操做去完成，可是经过前面对逻辑代码的分析，若是咱们将异步回调操做使用async/await的方式转换成同步的写法，那么逻辑代码大部分均可以看做是一种串行式的执行过程，偶尔叠加一些if/else的分支判断，这样也很是符合人们经常使用的思惟模式，理解起来很是直观。因此从编排的角度说，就是将不一样的逻辑节点和分支判断节点串联起来，布局上不须要太多的灵活性，同时连线操做也显得比较多余，所以咱们将拖拽连线所有改为添加节点的方式，而后自动连线便可。

采用这种自动布局的方式会大大简化用户的操做，用户只需关注核心的业务逻辑流程，按顺序添加节点便可，但同时也带来一个问题，因为分支类型的节点会产生两个分支流，若是遇到嵌套分支的状况下，须要自动将上层分支的横坐标的位置统一贯右偏移一个单位，不然处在上下层不一样分支上的节点位置可能会产生重叠。为此，我设计了一自动布局算法，最终实现的效果图以下：

算法过程比较简单，采用的是DFS深度优先遍历算法，详细过程这里就再也不赘述。

代码与schema互转

逻辑图编排完成以后，紧接着面临的问题是如何保证编排后的逻辑正确的运行，产生和源码同样的效果。一开始讨论的有两种方案，第一种方案把整个逻辑当作一个事件流，按照前面设计的逻辑编排schema，经过事件注册监听的方式完成逻辑节点的上下游串联，最后设计一套事件执行器，依次触发事件便可。这种方式实现起来比较简单，可是对原有开发流程的侵入性比较强。由于原有保存事件函数的地方都要被替换成逻辑schema，同时负责code review的前端同窗看到的再也不是代码diff，而是schema的diff，这无疑会大大增长了CR的风险。所以通过一番讨论以后，咱们决定采用第二种方案，将逻辑编排后的schema自动转成代码，同时生成后的代码也要可以自动转回schema。

基于schema转成代码是比较容易的，由于每一个逻辑节点自己就映射了一段函数片断，而将代码转回schema则稍微有些复杂。这里主要利用了Babel先对代码进行解析，获得抽象语法树AST，而后遍历AST中类型为statement的节点，最后经过正则匹配找到对应的逻辑节点，并串联好连线便可。下图就是生成好的一份代码示例：

能够看出，经过schema生成后的代码与源码编写仍是有一点区别，带有一些逻辑编排的特征，可是可读性更强，从代码基本也能直观的反推出逻辑流程图，反而从必定程度上下降了code review的成本。整个AST解析的过程以下：

断点调试

对于写业务逻辑来讲，不可避免的须要调试功能，这对有编程能力的同窗来讲是件很天然的事情，可是当逻辑变成经过可视化的编排以后，如何让这些”非前端“用户也能方便的经过调试定位错误，变得也尤其关键。

调试其实本质上对用户来讲，就是须要一个可以让编排后的逻辑模拟运行起来的过程，所以咱们对逻辑节点的各个环节作了埋点，用户在模拟运行的过程当中就能查看每一个节点的数据状态、上下文参数、报错类型等，同时根据逻辑流程图的状态（绿色表明执行成功，红色表明执行失败）也能很是快速的定位问题所在，以下图所示：

目前调试功能还处在初级阶段，后面还会持续迭代优化，好比调试时增长单步执行功能，像浏览器的单步调试工具同样进行断点。

总结展望

总结

目前，可视化逻辑编排已经搭载集团内的iceluna低代码搭建平台正式上线，并已经在营销工具业务中正式使用。从低代码向无代码的研发模式升级仍处在探索阶段，过程当中避免不了会遇到不少问题，但也算迈出了关键性的一步，值得期待。

展望

前面提到，从ProCode->LowCode->NoCode，经过下降研发门槛，让非技术人员参与到应用开发中来，能够大大提升生产效率，但理想很丰满，现实也很骨感，NoCode搭建平台我认为目前还只能在比较垂直的场景中才能适用，而且因为不像LowCode同样仍然可以写代码的逃离机制，经过NoCode的方式可能只能完成一个70分左右的产品。可是换一个角度去看，若是可让一个非技术人员，只用很低的门槛就完成一个70分左右的产品(最小可用产品MVP)，并能直接推广到市场去试错，若是验证可行，再经过转成LowCode或者ProCode的方式继续迭代优化。光这一点我认为就是颇有价值的，是推进商业创新的核心驱动力。所以我认为将来的产品研发节奏多是从NoCode->LowCode->ProCode，每一流程都要有对应的解决方案，而且互相之间可以相互打通，只有这样才能在竞争日益激烈的市场环境下更好的生存。

• 做者：凌乙