做低代码引擎有多难？OneCode五个版本历程心路历程

　　今天有幸跟处于头部位置的几家低代码企业技术负责人在聊天，低代码从最初的一个RAD（单页模型）到大前端，工程化，再到企业中台PAAS应用。直到现在的云原生嵌入式引擎技术，低代码技术一直冲在技术潮流的第一浪头。
　　回过头来看OneCode的经历，五个版本的迭代。一，V1。0SPA单页应用
　　第一个表单SPA应用
　　不管是现在大名鼎鼎的React还是国内风光一时的VUE，在1。0的哪个时代都在应用同一个概念SPA单页应用程序。
　　百度百科对SPA是这样定义的：
　　单页Web应用（singlepagewebapplication，SPA），就是只有一张Web页面的应用。单页应用程序（SPA）是加载单个HTML页面并在用户与应用程序交互时动态更新该页面的Web应用程序。
　　同时还有一个更为大家的熟知的概念MVVM开发模式（前后端分离），即前后端各负其责。OneCode1。0也出生在这个年代，CodeBee团队在多年工作流表单设计器的经验基础上。废弃了旧有的ext模板渲染模式，将组件进行全新的SPA模式封装。同时构建了第一批OneCode前后端一体的组件模型。在原有的技术体系框架中，逐步替换流程列表，表单应用。二，V2。0低代码引擎雏形，全站拖动计划
　　SPA的改造并不是一帆风顺的，在改造的过程中，团队无法适应前后端分离开发，前段组件构建的时候灵活度太差无法适应用户需求等等问题，一次次让产品的模型在新旧模型间不断转换，永远都存在无法消灭的最后一个模板应用。但随着团队的技术进步，产品上线后SPA在应用上带来的新技术体验，让OneCode1。0逐步的向主流的Vue，React靠拢。团队的技术欲望也不再满足于自定义表单，列表这样单一的应用。要支持全栈可定制，支持全栈可拖拽，DD（技术小伙伴们应该都能看懂）计划启动乘风而上。
　　至此，OneCode在2。0中实现了第一个基于SPA的DD，也有了DD的梦想三，V3。0Python，PHP哪个是最好学的语言？都不是，是DD！
　　OneCode3。0最是风光，全站DD，但飞的越高摔得越狠，去年5月份阿里团队发布了开源低代引擎OneCodeEngine，在开源的社区里讨论最热闹的话题之一是如何构建一个多页的应用。阿里官方的小伙伴甚至还专门为这一个话题发布了两期视频专题讲解扩展插件开发。
　　由一个单页应用扩展到多页应用，表面上只是一个存储文件的API操作。但实质上却是技术原理上本源上的跳跃，单页应用时所有应用都在一个环境内，可以直接调用，而相关的可视化读取也是静态结构。但如果是多页应用这就会面临很多的问题，跨页调用时可能新的页面还没有加载，更无从读取其函数列表及对象结构，可视化就被无形中中断。页面加载上了还必须考虑到新的界面可能由不同的团队开发的，在结构上甚至是全局变量命名空间上都会冲突。而将多页扩展到整个项目工程时，多达几百个页面不同的层次的加载关系。就使得复杂度产生了数量级的跳跃。
　　3。0版本开启多页工程化应用
　　OneCode2。0架构出现了致命的缺陷，OneCode3。0临危受命。工程结构树形结构及系统开发需求，直接催生了后端的OneCodeVFS共享存储体系支撑。多页面，多层级页面迫使SPA采用了支持package结构前端类结构体，而页应用也必须支持独立而严谨的装载机制。JavaScript单页环境这个小魔鬼也被关在了单页类结构这个沙箱里，多个SPA终于可以相互照应和平相处了。四，V4。0OneCode超级大前端直面API
　　3。0是幸运的，整个结构性的创新和变革，使得那个DD产品梦想能够继续，开始实战，一个DD超级前端程序员，在项目产品经理的领导下，快速而漂亮的完成了前端第一版原型，DD在丰富组件库的支持下，初步显示了其快做，快改，快上的特点。但眼见为实还是无法避免，组件拖动组合的硬伤，界面结构复杂，数据应用交互命名错乱，数据结构臃肿缺少体系性结构性的梳理，让后期才逐步介入的后端团队差点陷入崩溃的边缘。
　　前后端分离，先前端再后端的viewfirst（视图优先）模式，很快就破产。后端团队开始了全新的API设计，在业务相对定型前端结构初步完成时，后端API设计，其集约型严谨性得到了大幅的提升与之配套的文档以及测试用例也是应有尽有，后端团队出色的验证了codefirst（代码优先）所特有的模型建设优势。
　　皮球成功踢给了这个前端。前后端颜色的战争拉开了帷幕，接口参数命名规范，业务逻辑调转调用顺序改变、特有应用前后交互。。。在一次次的开会、文档交互中将两只大军陷入了书山会海。
　　DD真的只是梦想吗？不！CodeBee团队在困难面前是从来都不会退缩，V4版本在多个项目产品的前后端分分合合中逐渐归一。
　　后端为可视化应用逐步增加了，接口参数说明、组件绑定描述、事件回调支持等多种可被图形注解描述（可被前端直接图形化的注解），这样在前端可以在后端更新新接口信息，及参数时可以动态通知用户，并提供基础的参数校验。前端也进一步将组件化拆分为事件、动作、组件、属性等等，序列化后给后端应用。方便后端应用在权限拦截，页面与编译，公式执行等多个方面充分发挥其优势。Module模型应用DSM建模工具也在产品经理的极力推荐护航下启程上马。
　　DSM除了在前端实现了标准化组件定义外，还通过领域模型将二者打通。这样在前端组件建模时便可以直接调用后端服务模型完成数据部分API构建。而DSM模型工具也可以在后端建模时直接读取前端组件属性，打通前端动作与后端服务的通讯能力。
　　DSM作为DD新成员很快也得到了大家的认同。
　　视图设计器通过，后端模型绑定插件快速选定后端Agg聚合服务模型接口，配置页面快速绑定前后台交互
　　后端DSM建模通过视图模型扩展直接修改操作，前端组件模型
　　五，V5OneCodeEngine赋能低代码
　　V5版本，OneCode进入了一个全新的时代，长达将近2年的封闭研发，彻底剥离清除项目痕迹，针对600余中前端组件进行全面的标准化重构。全面改写OneCode服务端，将OneCode注解体系直接扩展扩展至Dom原生支持。针对600余种组件常量常见动作梳理出完整的枚举结构图，在此基础上与DSM模型进行了深度整合。并确定其核心价值：
　　OneCode是一款构建在真实代码之上的图形化编程系统
　　OneCode是一款具有全站组件支持能力全面标准开放全栈低代码应用支撑系统
　　OneCode是一款以领域模型（DDD）为指导，以Java为基础语言的特定领域（DSM）模型构建系统
　　OneCodeEngine呼之而出！
　　全线的辅助验证管理工具也全线登场。
　　首先是，全系列管理端工具插件的V5重构验证。工具类应用本身就是非常复杂的界面组合，而将这些界面功能以高集约的方式展现在Web环境上时还有全面的保留其DD的特性，在性能响应上也要能够满足开发者高频的使用。这对于底层引擎而言是非常严苛的考验。OneCode家族一个新的成员OneCodeStudio来到大家的面前。OneCodeStudio本身也是一个低代码工程，但这个工程将所有的管理端界面以及插件工具纳入管理范围，并且从底层解构，为插件及管理工具开发者提供了一套完整的仿真调试工具，方便对平台的扩展。至此OneCode本身完成了低码应用重构。同时也很好的验证了，低码本身在复杂应用中的适应性。
　　OneCodeStudio工具集合
　　六，开源工程支持范围以及OneCode（JDSCloud智能云）
　　自从阿里去年4月份开源其LowCodeEngine低代码引擎以来，CodeBee团队就在筹划开源版本的建设，在JDSCloud初步第一个版本初步测试完毕的空档，决定在近期发布第一个OneCode开源版本。
　　OneCode开源范围及功能：
　　OneCode第一个版本，以V5版本的引擎为核心，将平台全部600余组件的23贡献到社区版本，同时为方便大家构建自身的工程体系，还会同步开源OneCodeV3版本的支持环境VFS（JAVA开发）虚拟存储系统，以及配合V3部署使用的OneCodeServer和相关的部署管理插件。
　　V4及V5部分由于其技术成熟度以及商业层面的考虑暂时不能在当前版本中发布，但为了方便大家自定义组件测试以及开发插件需求，我们将推出JDSCloud的在线开发与编译功能。大家可在线使用一码通编辑器来编写和测试插件程序，测试完毕编译打包下载即可。
　　一码通在线编辑器七，开源版本未来计划
　　OneCode从一开始就是站在巨人的肩膀上的。每一步的前行都离不开开源社区的滋养，特别是来自于Java体系的开源小伙伴们，OneCode最终的归宿也将是全部回馈社区，这是CodeBee团队所有成员的最终愿景。
　　作为回馈社区的第一步，我们将尽心最大的努力积极参与社区的版本建设，为社区提供持续并稳定的技术支持。
　　作为低代码开源社区的一员，OneCode也将积极参与社区的标准化建设。在下一版本中，OneCode会将最大程度兼容社区老大哥阿里LowCodeEngin，并适时优先推出OneCodefor阿里LowCodeEngin，在组件及物料跨平台通用方面迈出坚实的一步。
　　2023年2月10日凌晨，首发于文章JDS头条号。