低代码平台使用两月真实感受

2022-02-03 From 程序之心 By 丁仪

近几年低代码着实火了一把,各种平台层出不穷,网上大把的帖子说着上了低代码半数人都要被辞退了(自媒体贩卖焦虑太溜了)。

有幸在前端同学的极力胁迫,哦不,推荐下,也在业务中使用低代码平台搭建了几个页面。总体来看,差强人意。

“预设”悖论

“预设”是德国哲学家、现代逻辑奠基人弗雷格于1892年提出的概念,指的是说话者在说出某个话语或句子时所做的假设,即说话者为保证句子或语段的合适性而必须满足的前提。

“预设”悖论并不是低代码独有的,所有的架构设计都会遇到这个问题。无论是分层架构,还是六边形架构,都在试图用“预设”的概念、模型、扩展来抽象问题,从而降低复杂问题逻辑难度。

比如我们描述一个商品,基本的信息包括标题、主图、价格、库存、详情描述,复杂一些的会有 SKU、主图视频、端图、运费等。当我们基于这样的商品信息去建模的时候,很容易把商品模型拆解为商品域、营销域、履约域等多个子域,也可能划分为文本、富文本、多媒体、价格、库存、SKU、扩展信息等多个类型。

无论用什么方式去建模,都无法回避的问题是“要先有业务需求,然后才能沉淀模型,再去用模型赋能业务”。这样就会有“预设”悖论,到底是先设计模型还是先承接业务。如果先设计模型,会不清楚业务的发展方向,模型大概率短期合适长期成为瓶颈。如果先承接业务,很可能无法及时沉淀模型业务代码屎上雕花,以后也不会有人关心了。所以大部分系统都不可避免,要一直重构、多次重构。

这很像人的语言迭代,弗雷格提出的“预设”就是人这个群体自然演化出的语言能力。战国时期“美人”可以指代“国君”,21 世纪大家都会理解成“美丽的女人”。26 个字母曾经与汉语毫无关系,现在却变成拼音成为汉语的重要基石。重构,本质上就是重新认识业务、重新理解业务、重新设计模型,实现“预设”模型的迭代更新。重构可以是局部小重构,也可以是全局的大重构,取决于 ROI。

低代码平台现状

低代码平台通常的宣传都是围绕沉淀好的模型、组件来降低搭建成本,实现页面快速上线。基本都有以下功能模块:页面搭建、数据逻辑数据模型、在线部署和管理系统。低代码的效率提升,本质上就是基于“预设”实现复用。低代码主要有两种:界面驱动,表单/数据模型驱动。

界面驱动就是预设页面组件以及前后端统一实现,用户通过拖拽组件方式可视化搭建界面,然后配置页面的交互逻辑,比如页面的跳转、数据获取。复杂一些的页面功能,比如涉及组件联动、组件异步拉数据,低代码平台也只能实现少量确定性的联动,复杂交互还是需要让使用者手写代码实现。

表单/数据模型驱动围绕数据结构来定义整个应用的形态和流程,核心在于搭建表单和定义数据,可以用于 CRM、ERP 等管理系统做二次开发

与其说低代码是为程序员提效,不如说为程序员提供一个“针对特定场景”的“二次开发环境”,核心还是基于复用来写代码。学习一个低代码平台的使用,本质上和学习一门新语言区别不大,学习成本、经验积累都需要考虑。

而现在各个低代码平台看起来并没有统一的技术体系,迁移到低代码平台和在平台之间迁移成本都非常高。程序员要想职业生涯发展顺利,需要持续积累和复用专业知识、专业技能,目前的低代码平台对程序员而言完全站在了对立面,不利于程序员的长期发展。核心程序员要么专注于解决业务领域核心问题,要么参与低代码平台的底层建设。基于低代码平台的二次开发,建议交给外包去完成。

另外,基于低代码平台进行二次开发,必然有确定性的业务场景,这样的业务场景能否回流到平台促进平台模型的进一步迭代,在业务发展和平台能力提升中形成良性循环,不只是低代码平台遇到的问题,更是每一个架构设计需要深入思考的问题

本文来源:程序之心,转载请注明出处!

本文地址:https://chengxuzhixin.com/blog/article/303470.html

发表感想

© 2016 - 2022 chengxuzhixin.com All Rights Reserved.

浙ICP备2021034854号-1    浙公网安备 33011002016107号