【技术干货】低代码产品建设弯路思考

【引言】如今市场上低代码产品多如牛毛,真正商业化非常成功的就那么几家。阿里系、网易系、腾讯系大厂出品,背靠丰富的云资源和巨大的流量入口,独占鳌头。简道云、得帆云、活字格等垂直领域的低代码厂家,潜心打磨产品功能,个性化定制业务需求,也能占有一席之地。而我要分享不是大而全的产品体系,而是一个深耕公司内低代码搭建复杂业务页面下的研发视角。本次分享的是,一个目标在于满足公司内部中后台业务页面搭建的"既成功又不成功"的低代码产品。成功在于,它确实支撑了公司10+业务线,3K+中后台页面的搭建,为产研团队提升了很大的研发效率。不成功在于,随着市场低代码产品的推陈出新,业务已经逐渐不满此产品的功能扩展性和场景覆盖范围(此背景下延伸出开发新的搭建平台的诉求,这是后话,后面会继续分享)。

下面将从前后端不同角度详细描述为什么这是一个"既成功又不成功"的低代码产品。

功能介绍数据流图 当前产品功能提供了:

  • 应用、页面、视图等基本模块,可以通过不同的组合(区划、机构、类型等维度)访问到页面下不同的视图。
  • 通过视图可直接生成政府公告,页面数据可通过通用接口直接生成政府公告文件
  • 可与待办、工作流集成,完成审核流业务以及待办消息推送

以上功能基本覆盖了政府类业务的中后端页面的半壁江山。与工作流集成交互如下

看到这,这不是挺好的一个产品吗?又为什么不成功呢?请看如下讲解:低代码,顾名思义,与页面搭建不可分割。所以在渲染引擎的技术选型上至关重要,可以说渲染引擎是低代码产品一切的基础。然而当前产品的渲染引擎思路如下:

渲染引擎流程

在技术选型上,并未使用开源的低代码引擎框架,而是团队内部封装了一套渲染引擎。并不是说非要使用开源的低代码引擎框架,而是造轮子需要具备足够的技术积累和团队配合,不是一个小的前端团队能够完成的工作。如下就是自己封装导致的缺陷:

  • 未做好整体规划,只是以实现公司业务目标为准则。设计上并未将产品本质定义为一个低代码框架,而是封装成高级组件,引擎只能识别封装过的组件配置schema,业务侧研发无法自定义扩展组件能力。以至于每一次功能修改都需要搭建侧前端研发修改对应渲染工具包,发布版本之后才能生效。
  • 作为物料实现,schema定义是组件,而不是渲染器。所以页面渲染的代码逻辑每个步骤都是写死的,必须依赖最外层是容器组件(容器组件可以理解为基础组件,例如文本、数值组件的包装盒)时schema才能被解析,容器组件中也只能添加基础组件,公司其他组件库中的组件不支持兼容。

上述的设计也导致了渲染上只能通过递归嵌套的方式才能解析,如下所示

由此,无法扩展性的设计缺陷导致在复杂组件自定义上,业务前端开发无比痛苦。业务个性化需求只能依赖本产品研发,自然也就造成了人力瓶颈。

缺点:

  • 难维护,组件不易扩展

  • schema结构定义不规范,解析和组件升级困难

  • 多环境组件各自升级,无版本概念,无法租户隔离

接下来说到服务端,为了让接入业务通过更少的代码接入和具备更丰富的接入能力,服务端提供了四种接入方式。

  • 支持纯前端(只提供schema调用和渲染)
  • 中心化接入(页面、数据都落在搭建库)
  • API接入(通过OpenApi形式完成与业务交互)
  • SDK接入(给业务提供完整SDK,以rest接口形式提供表单和数据处理能力)

这样看,能力不是挺强大的吗?确实,四种接入方式确实覆盖了所有从简单到复杂业务的接入范围,优点很明显:

  • 支持多种方式接入

  • 支持与工作流、待办的集成,功能强大

  • 支持后端复杂功能扩展

但是缺点也十分明显

  • SDK接入量大,虽然扩展性能力强,功能强大。但是随着公司组织架构调整和对应业务负责人变动,上手难度大缺点逐渐凸显出来。随着公司通用架构组件升级以及国产化改造等,需要业务升级改造之后的SDK,在无法做到无缝适配或者需要业务测试全面复测的前提下,让业务对升级心有余悸(毕竟故障直接影响money)。

  • 没有通过模型的概率抽象业务逻辑,只能通过解析schema获取组件中字段的属性,代码极难维护。且在无模型的情况下,只能支持单表的表单操作,适用场景少问题也凸显出来。

【思考】

这个产品的弯路给人的思考很多,在最近一段时间,像【黑神话】3C游戏、【哪吒:魔童闹海】电影、宇树科技四足机器人等等大爆现象,无一不说明长期主义对一个优秀产品的重要性。虽然,公司是一年一度的打绩效、发奖金,但是作为一个有思考有担当的应用owner,还是需要从长期规划产品的建设路径的。想强调的是,当前的痛点已经无法通过日常的需求迭代完成根本性的变革,必须使用更具扩展性和易用性的渲染引擎和能够抽象业务逻辑的模型以及事件流完成从客户端到服务端复杂搭建逻辑的闭环。所以,产品需要在产品建设初期就要考虑到几年后的使用形势(虽然大部分人无法看到,或者说只是实现需求的工具人)。否则,只能自己坑自己。

希望通过此文章能够给有耐心看到这块的朋友们一些启发。ending

相关推荐
无懈可击8 小时前
FormCreate低代码表单设计器 v3.3 版本发布,功能大更新!
vue.js·低代码·开源
NocoBase12 小时前
GitHub 上 Star 数量前 8 的开源 Web 应用项目
低代码·开源·资讯
wenzhangli71 天前
低代码引擎核心技术:OneCode常用动作事件速查手册及注解驱动开发详解
人工智能·低代码·云原生
欧雷殿3 天前
超越 Vibe Coding 的智能研发
低代码·aigc·ai编程
zzywxc7873 天前
AI技术正以前所未有的速度重塑职业生态与行业格局,尤其在自动化测试领域,AI驱动的测试框架通过智能化、低代码化重构传统测试流程。
网络·人工智能·经验分享·低代码·重构·实时互动·电脑
wenzhangli74 天前
AI+低代码双引擎驱动:重构智能业务系统的产品逻辑
人工智能·低代码·重构
Codebee4 天前
OneCode注解驱动:智能送货单系统的AI原生实现
人工智能·低代码
阴阳怪气乌托邦4 天前
低代码遇上Vue3,是“降维打击”还是“最佳拍档”?🤔 上手后我直呼“芜湖”!
低代码
Codebee5 天前
AI驱动的低代码革命:解构与重塑开发范式
人工智能·低代码·代码规范