零标识符网络平台
零标识符网络平台
具体来说无论是低标识符还是无标识符，都是针对特定场景或者细分领域的，比如说运营的活动页，中后台的表单，表格页面等，因为只有在这些场景下，后端交互相对收敛，能够沉淀出足够多的组件物料，从而透过可视化的形式拖拽组件就能够直接构筑出页面。
现阶段我所在的团队正在研究面向营销域的中后台后端软件系统。通常来说，中后台软件系统的核心目标是提效，提效包括两个方面，一方面是对研制人员的提效，另一方面是对用户的提效，提效的核心抓手在于生产关系的变更，由后端合作开发向后端，视觉，产品各方面参与发展，从而降低后端研制的门槛，提高生产效率。提效解决的不是20%的个性化增量需求，而是解决让非后端参与进来，解决80%的通用型需求。中后台的提效路径大部分走的都是ProCode->LowCode->NoCode形式。零标识符网络平台
表面上看，从ProCode->LowCode->NoCode看起来好像只有很小的差别，好像只有标识符量多少的问题，但整座过程早已从量变发生了质变。ProCode和LowCode主要面向的还是一些须要有后端编程能力的人，而NoCode则代表非后端也能够参与的后端的页面构筑中来，这里面不是说完全不须要标识符，因为今天哪些算标识符其实比较难界定，比如说用户撰写一个实用性文件，这个文件是json格式的，那到底能不能算标识符？所以，NoCode的意思不是说没有标识符，而是说在于用户学习门槛和学习成本的降低，普通用型户不须要经过艰难的学习就可以做到以前程序要编码才能同时实现的事情。
零标识符网络平台
可以看出，要形成这样的逻辑图谱，本质上是须要对不同逻辑节点进行组合和串联，真正的逻辑由封装在节点中的函数顺利完成。那么这里就产生了两个问题，具体来说是怎样抽象逻辑节点，抽象出的逻辑节点能不能被复用直接决定了用户编排的成本，如果须要不断的定制个性化逻辑节点可能就失去了编排的意义；其次是逻辑节点的的颗粒度大小也非常关键，如果封装的逻辑颗粒度太大，大到一个功能服务，那么可能就变成了业务流程编排；如果颗粒度太小，小到一个表达式级别，那么对于有编程基础的同学来说，可能直接写标识符效率反而更高。零标识符网络平台
透过对中后台营销域的部分业务标识符进行梳理，发现中后台的页面大都是以表单、列表，详情为主，而其中90%的业务逻辑基本上都围绕在表单(校验，取值，赋值，提交)，对话框（显隐、提示），发送请求，消息提示，数据处理，路由跳转，条件判断等，相对比较收敛。同时iceluna作为集团公司内优秀的低标识符构筑网络平台，在上层封装了许多非常好用的api，屏蔽了大部分后端语法层面的差异，比如说状态赋值，页面刷新，接口调用，一些常用的工具函数（时间处理）等，为逻辑节点的抽象提供了极大的便利性。
透过分析归类，最后沉淀了10个左右的逻辑节点，如下图所示，同时每一个逻辑节点最终本质上都是对应一段执行函数，并接收一个参数作为入参，返回一个参数作为出参。
▐零标识符网络平台编排协议
由于是可视化编排，自然也避免不了编排的协议，为了避免重复建设最大程度的复用集团公司内已有的编排方案，最终计划采用LF通用型可视化逻辑编排的协议来同时实现iceluna中的逻辑编排。
算法过程比较单纯，采用的是DFS深度优先遍历算法，详细过程这里就不再赘述。
▐标识符与schema互转
基于schema转成标识符是比较容易的，因为每个逻辑节点本身就映射了一段函数片段，而将标识符转回schema则稍微有些复杂。这里主要利用了Babel先对标识符进行解析，得到抽象语法树AST，然后遍历AST中类型为statement的节点，最后透过正则匹配找到对应的逻辑节点，并串联好连线方可。下图是生成好的一份标识符示例：
可以看出，透过schema生成后的标识符与源码撰写还是有一点区别，带有一些逻辑编排的特征，但是可读性更强，从标识符基本也能直观的反推出逻辑流程图，反而从一定程度上降低了code review的成本。整座AST解析的过程如下：零标识符网络平台
▐零标识符网络平台断点调试
对于写业务逻辑来说，不可避免的须要调试功能，这对有编程能力的同学来说是件很自然的事情，但是当逻辑变成透过可视化的编排之后，怎样让这些非后端用户也能方便的透过调试定位错误，变得也尤为关键。
简道云植根于低标识符领域十余年。简道云现阶段拥有 50 多个 SaaS 应用领域，几乎所有应用领域都可以透过 简道云 的低标识符合作开发进一步合作开发和定制。 简道云 还支持第三方应用领域的合作开发，无需标识符，方可构建出符合需求的业务管理系统（如生产管理、进销存等）。
