Last Surprise Lyn
  1. 1 Last Surprise Lyn
  2. 2 Warcry mpi
  3. 3 Time Bomb Veela
  4. 4 Hypocrite Nush
  5. 5 Life Will Change Lyn
  6. 6 One Last You Jen Bird
  7. 7 Libertus Chen-U
  8. 8 Flower Of Life 发热巫女
  9. 9 BREAK IN TO BREAK OUT Lyn
  10. 10 かかってこいよ NakamuraEmi
2019-12-15 16:18:49

《低代码平台》分享文字稿(上)

最近几周没时间写博客,主要是一直花时间(顺便补了打越的999)在整理这个在公司内部分享用到的一个ppt以及文稿,做分享的一个目的是安利一下我写的框架,也算是来b站半年来主要花时间做的东西。另一个目的就是相当于一个总结与记录吧,学到的以及用到的知识只有总结成体系才不容易忘。第一次分享会也结束了,文稿基本定型,所以在博客这里分享给大家。内容比较多,分成上下两篇。

第一页——介绍

大家好,我是来自前端技术部的折梓,首先感谢大家抽出时间来听这次分享,今天我要分享的主题围绕两个点,中后台开发,低代码平台。前者是问题,后者是方案。在谈到解决方案之前,先看一下中后台开发目前存在什么问题。

第二页——展示现状

首先就是多。这不算问题,应该说是中后台开发的一个特点。因为每个稍有规模的项目都免不了对数据进行处理,小到博客,大到我们整个主站,这是我从OA上截的一张图,可以看到,有大量的后台管理系统。每个后台项目都由各个独立的项目组维护,开发方式和写一般的前端项目没什么不同,都是借助优秀的三方组件库,比如Element或者自己项目组沉淀的一些组件开发并维护,属于最传统的开发模式。

第三页——说明问题

传统开发模式本身没有问题,但是因为中后台需求的特性,再加上量大带来的质变,两者结合就产生了问题。因为中后台的需求都是围绕着数据进行处理,离不开curd+展示,就造成了大多数情况下,我们编写的代码模式及其重复。相信有过后台系统维护经验的人都有过这样的经历——接到一个新的页面需求开始开发时的第一件事,就是找到一个类似的页面,COPY AND PASTE,然后再根据后端文档改改ajax方法里的url和传参,表单和表格组件的model,最后再看数据怎么展示,再去找对应的表单组件复制粘贴过来。最后再修一些细节就可以提测了。中后台开发就是这么的朴实无华且枯燥。但这些虽然重复繁琐,却又是不得不做的工作。

第四页——问题展示

我再以我们项目为例,举几个具体的例子。一,代码模式重复率高,比如fetchData这个为代表的一系列和数据交互的方法,过滤的时候要fetchDatawithquery,提交的时候要处理fetchdatawithform,我们在每个页面中都要一遍又一遍的写。其二,风格混乱,比如表单验证,有直接在提交方法里做的,有单独抽一个方法的,也有html上验证的。当然我们可以用什么表单工具约束,但这只是一个小代表,要约束的地方不止有表单,应该是所有可以重复的地方。其三,不易维护。时间长了就涉及到组件的更新和替换。比如我们项目里的FormItem和FormGroup来处理表单布局,职责比较相似,我到现在也搞不清楚这两个组件的区别,如果有一天想把这两个组件合并。或者干脆换一套统一的表单方案,那旧代码处理起来就很麻烦了,只能让新老代码共存。

总结一下就是,可以简单重复的模式仍然在用手工维护。鲁迅曾经说过,越是简单的东西越容易出错,我自己的一个体会就是,写复杂需求精力更集中,一但重复写法太多,就很容易在细节上出问题,比如一个表单字段传的参数稍有变化,由必填变成非必填就很容易忽略,反而被测试测出的bug会多一些,虽然改起来快但总是个麻烦的事。每个后台管理应用的基础设施是相同的,部分的代码逻辑也是相同的,它们可能只是数据模型不同而已。结果却导致了要一次又一次地重复编写大量相同的页面。一直重复的过程中,我们其实就应该想一下,是否可以有更好的解决方案?也就是我今天要谈到的另一个关键词了——低代码平台。

第五页——抛出解决方案

那么首先要解释一下低代码平台是什么。 实际上这并不是一个新概念,从早期的DreamWaver到现在百度的amis,美团的乐高,阿里的飞冰,云凤蝶等等,都在尝试通过低代码的手段降低应用开发门槛,提高生产效率。核心特点有3个:1. 面向开发人员 2.支持可视化配置 3. 跳过基础架构和代码细节的快速开发。 可以看到和低代码相对应的还有no code和pro code两种模式,pro code就是我们的常规JS代码+组件开发模式,no code就是H5页面搭建那种在编辑器中不写代码通过拖曳就能生成页面的模式,low code就算在两者间的权衡。三种不同的编码模式本质上也就是代表了三种不同的封装层次,有不同的特点和适用的需求复杂度。

第六页——不同模式特点

在说到如何设计一个低代码平台之前,我先说明一下为什么低代码平台适用于中后台开发,因为包括我自己,大多数开发者对于可视化编辑器的第一反应其实是排斥的。最直接的理由就是:有使用上的学习成本,不如手写代码灵活。确实是这样,封装到越上层,就越不灵活,编辑器很难应对平时复杂多变的需求。但我们需要搞清楚这个问题的本质。

我们平时处理的需求是属于高复杂度的一类,特点是灵活,对应到三种层次,最适合的其实是Pro-code,用上面两种手段去处理都是不对应的,就会体现出灵活不足的问题,我们排斥编辑器的本质是想用它处理不合适的需求。那么我们回过头来看中后台开发,需求强度应该在中间,这时用编辑器其实就很合适了,能做到复杂度和封装层次对应。再想想为什么之前用pro-code的模式去处理中后台需求会有那些重复问题,本质还是封装层次过低,和需求复杂度不对应,中间的差异就要用重复编码弥补。

第七页——中后台通用模式

具体来说,不讨论UI展示和交互细节的情况下,90%的后台管理页面的需求复杂度都可以简化为这样一种模式: 首先是新建数据,把数据提交到外部API,再从外部API的列表接口获取数据展示。有了数据后就可以编辑或者过滤,最终都要落到展示上,整体形成这样一个流程图。然后其中的新建和编辑可以封装为表单组件+逻辑代码。和API交互的部分可以封装为ajax+逻辑代码,展示数据的部分可以封装为表格组件+逻辑代码。这些被封装的部分就算是LOW CODE了。

第八页——DSL封装

然后用一层DSL表达出来,比如说用JSON。ajax+重复逻辑代码用一个特殊的API字段表示。表单+重复模式代码,用type: form + API + 表单相关的props表示。展示组件+过滤组件+重复模式代码用type: curd + API + filter表示。最后我们只需要解析这个JSON就能直接得到需要的页面了。

第九页——缺点

那么再看LOW CODE模式下的缺点,比较关键的有两个点。但因为我们把场景限定在了中后台开发下,所以这两个缺点都可以忽略。目前有很多低代码平台,核心思想都是相似的,但是根据解决问题的场景不同,有很多设计上的细节会有分歧。之前看云凤蝶团队的分享,他们产品在早期定位不明确的时候,按照中后台的思路去做,结果接到的第一个需求是门户类页面的开发。做的非常勉强,做出来还不能完全满足需求,别人不买帐,又推倒用手写代码的形式重做了一份。所以限定场景,想清楚要解决什么问题是很重要的。

第十页——优点

最后看优点就比较明显了。我们从开发流程的每个节点上来看:

首先是产品提出需求,中后台系统的特点就是产品来自各个产品团队,每个开发团队也有各种各样的中后台,基本呈现一个多对多的状态。产品第一件事肯定是看这个中后台的表现,设计上尽量保持风格统一。这首先就是个花时间的地方。有了框架的统一模式约束,所有中后台风格统一,产品就可以把关注点聚焦到最核心的地方,如何展示数据,如果操作数据,不用再考虑一些细枝末节的地方,比如搜索按钮放在哪里,批量操作按钮放在哪里,这些按钮什么颜色,表单验证的错误提示放在哪里。这些怎么表现不重要,统一的表现才重要,所以全部由框架统一约束。

对于开发来说,编码时间缩短不用说,不用再关注重复细节,还可以利用各种工具比如cli和可视化编辑器。后续维护代价减小,组件的更新和维护都可以聚焦到框架内部,不同的项目组不用再考虑用什么组件库再做二次封装,用什么表单验证方案,这些都统一由框架提供。

测试时间缩短,因为框架内部保证了能配出来就绝对是稳定可用无bug的,测试只需要关注流程是否正确。

对于用户来说,降低后台管理系统的使用成本与心智负担,本质是框架对产品的约束进一步反馈到用户上,能保证所有后台系统的交互统一。我以前就接过一个需求,一个后台系统里操作的数据我这边会取到并展示,两边都是多选框,结果两边多选交互不一样,产品希望保持统一还讨论了很久。用了框架约束就不会有这种问题。

最后再谈NO CODE,为什么不用NO CODE的模式,本质还是封装和需求的统一,NO CODE 封装层级过高,主要面向用户。后台管理还有10%的页面需要手工维护,LOW CODE主要还是面向开发,对于可视化不能满足的需求,仍然要提供pro code自定义的能力。

到这里,其实我们对于一个low code平台有哪些要素有一个概览了。下面就谈如何设计一个这样的平台。

小结

上篇主要介绍中后台开发有什么问题以及对应的解决方案——低代码平台。下篇就分析如何设计一个低代码平台。

-- EOF --

添加在分类「 前端开发 」下,并被添加 「Vue」「设计模式」「工程化」 标签。