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

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

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

“预设”悖论

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

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

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

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

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

低代码平台现状

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

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

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

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

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

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

 

https://chengxuzhixin.com/blog/article/303470.html

标签：两月,感受,代码,平台,业务,预设,模型,页面
来源： https://www.cnblogs.com/chengxuzhixin/p/15865550.html