第三届搞搭建|月飞-如何设计实现中后台搭建

前言

Hi，大家好，今天非常高兴能有机会作为讲师，来给大家分享关于《如何设计实现中后台搭建 PaaS 平台》这个话题。今天的分享将围绕阿里淘系技术部飞冰系列产品中的中后台搭建产品 iceluna 来进行展开。

个人介绍

在正式分享之前，先自我介绍一下。我是来自阿里淘系营销中后台团队的月飞，负责中后台搭建产品 iceluna，以及《阿里集团中后台搭建协议标准规范》的推广和落地。2013 年加入阿里巴巴聚划算，负责 PC & 无线详情。2016 年加入天猫，带领营销玩法团队，负责玩法、互动类型业务。2019 年加入淘系技术部，带领营销中后台团队，负责中后台业务，专注于中后台搭建产品建设。

话题介绍

今天的话题是搭建，以面向角色的不同大致可以分为面向运营和面向研发两类搭建产品。面向运营的搭建产品主要是以可视化配置 ( No-code ) 的方式进行完整页面搭建，如营销活动页面搭建。面向研发的搭建产品主要以低代码开发 ( Low-code ) 的方式，搭建“中后台系统”或者“无线模块”，如商家、小二后台系统的搭建，无线 Rax 模块的搭建。今天我这边的话题是中后台系统搭建，跟营销活动类页面的搭建在面向角色和搭建模式上是非常不同的，接下来主要围绕 “ iceluna 产品 ” 和 “ PaaS 平台建设 ” 2 个维度来展开分享。

分享大纲

这是我分享的大纲，我会先对 iceluna 这个产品进行整体介绍，讲解下产品背景、定位及现状。第 2 部分会从架构设计、功能模块设计、研发流程设计三方面来介绍中后台搭建产品的设计思路，让大家对 iceluna 产品全貌有个基本认识。第 3 部分会着重从中后台搭建基础设施维度来讲一下 iceluna 是如何建设搭建基础设施的。第 4 部分则会回到 PaaS 平台这个焦点，来讲解 PaaS 平台需要建设的核心能力。最后会稍微做下总结和展望。

iceluna 产品介绍

产品演示

大家现在看到的是 iceluna 界面，因为目前产品还未开源，还未对外网访问，大家可以先看一下这是我们研发中心的一个站点首页，第 2 页是站点区块中心，在这里面可以看到区块市场，区块管理等内容，因为演示页面数有限，在这里还可以看到顶部 tab 还有组件和模块等物料管理。第 3 页是应用研发中心，里面有页面，应用组件，导航，数据中心，发布等等一系列操作的界面。最后这 1 页是 iceluna 的低代码搭建编辑器，这也是 iceluna 产品最核心的一个能力，总体界面和产品形态还是比较清爽，中间搭建的是一个商品列表页面。

产品背景

刚演示了 iceluna 几个核心页面，对整个产品有了一个基本的了解，iceluna 产品发展至今已经经历了 3 年半时间，产品一路迭代演进至今的低代码开发 PaaS 平台，背后有着一系列原因。在了解这些原因之前，想先跟大家普及一个概念，今天我们一直在提的“低代码开发”。对于 iceluna 通用搭建来说，有着自己的一点理解，它是通过可视化的方式，使具有不同经验水平的开发人员可以通过图形化的用户界面，使用拖拽组件和模型驱动来搭建网页的开发模式。

了解完这个概念，我们来谈下 iceluna 产品的背景：

中后台技术之殇：在淘系整个业务偏消费者端，中后台这一侧人力投入是偏弱的，这是目前中后台的一个困境。我们有大量的商家或小二操作系统，前端人力相当紧缺，大量系统依赖后端/外包/ ISV 负责研发，由于前端工程环境复杂，技术迭代快，门槛高，在效率/质量/体验/可维护性等方面存在较多问题，对于如何赋能？如何改善协作模式？传统源码模式已不能满足业务发展的诉求，对于低代码开发模式的需求日趋强烈。
低代码开发模式的崛起：据 Forrester 市场调研结果，通过低代码开发模式可带来数倍甚至 10 倍以上研发效率的提升。这对于中后台现状面临的一个业务压力，是我们非常迫切需要解决的一个问题，那就是如何提效的问题。它给了我们足够大的想象空间。近年来各大互联网巨头公司都以纷纷投入到低代码或无代码平台的建设上来。在阿里的话，各大 BU 也是重兵投入到这一块的。这也就衍生出来第 3 个问题，那就是搭建泛滥后的技术收敛和统一。
搭建泛滥后的收敛和统一：阿里内部各 BU 针对不同业务场景构建保守估计有数十个以上低代码搭建产品，投入成本巨大，能力完善程度相对不一。在搭建这块如何收敛和统一？完善搭建基础设施，由集团层面提供统一的搭建服务的运行和开发环境，是势在必行。我个人作为集团搭建协议的负责人，也是希望通过 iceluna 产品去解决这一块的问题，能讲 iceluna 演进成为一个搭建 PaaS 平台，去提供搭建底层服务的能力，服务全集团的搭建产品。

产品定位

目前 iceluna 产品有着 3 层定位：

中后台通用搭建产品：由淘系技术部研发，面向全体研发人员可用，打造一个中后台通用的搭建产品。由于淘系业务几乎以商家，小二运营操作系统为主，业务逻辑多，交互复杂，很难抽象固定场景的业务模版或可视化配置的解决方案。因此，需要我们低代码开发的中后台搭建产品具备有极强的通用性和扩展性，才能够 100% 覆盖复杂交互的中后台系统页面的搭建。
全链路低代码开发平台：集前端应用工程创建、开发、调试、发布，甚至到页面的托管，全链路一体化的低代码平台。屏蔽复杂的前端工程体系，全链路打通。
PaaS 平台：建设搭建基础设施，基于标准搭建协议生产搭建物料，为各业务场景提供搭建服务的运行和开发环境。目前 iceluna 的 PaaS 平台主要以以下 2 种模式提供服务：
平台模式：业务研发进入 iceluna 研发中心，全链路在 iceluna 平台上进行编辑器定制和运行，业务托管在 iceluna 平台上；
中台模式：脱离 iceluna 研发中心，对外将 iceluna 编辑器能力和低代码能力以 npm 包形式提供出去，助力于孵化各个领域场景的独立的低代码编辑器，独立部署。

然后，我们在目标设定上，对应有如下 3 个目标：

赋能：赋能是我们第一重要的目标，因为在目前中后台发展的业务现状下来说，赋能恰恰是目前最能消化中后台业务压力的一个重要手段，这是我们经过 2 - 3 年在业务上不断摸索下得出的一个结论，赋能可以通过后端、外包，改变与前端的一个生产关系，去改善和提升研发项目或者说总个研发团队的生产力，使得我们后端外包可以跨界的工作，减少一些不必要的依赖和成本。
提效：目标还是降低研发成本。提效一直是我们技术永恒的话题，但就 iceluna 现状来说，提效效果并不是特别的理想，在下一页现状会聊到。
搭建生态：希望成为一个 PaaS 平台或搭建中台，去孵化领域搭建产品，形成搭建产品矩阵，在各领域上有更高研发效率。

产品现状

iceluna 是一个面向集团提供服务的通用低代码开发平台，基于产品定位和目标，iceluna 在赋能、提效、搭建生态上均取得不错成果。

赋能：活跃用户数 1000+ ，后端占比 44% ，前端占比 39% ，测试占比 11% ，外包占比 7% 。从占比可以看到，有超过 60% 的用户属于非前端研发人员，在使用 iceluna 进行系统页面搭建。通过数据可以看到， iceluna 在赋能上有不错的效果。
提效：上线应用 440+ ，页面 6000+ ，覆盖阿里多个部门中后台应用研发，经霍尔斯特德软件复杂度算法模型测算(后面章节会介绍)，人均研发效能提升 200% 左右。
搭建生态：提供完备的搭建基础设施服务 & PaaS 平台服务，已孵化 8+ 业务场景定制的搭建产品。

iceluna 架构设计

架构设计

上图是 iceluna 产品从 PaaS 角度看的一张架构分层图，从图上我们可以看出，核心包含后端服务、搭建基础设施、PaaS 服务、研发中心、搭建产品 5 层。下面对每一层服务能力做介绍。

后端服务：基于 Node.js 的 Midway 框架实现的一个 Server 层，提供搭建平台数据接口和 Socket 服务。
搭建基础设施层：目标提供搭建编辑器的开发环境。核心包含中后台搭建描述协议、低代码编辑器、插件生态、物料生态 4 个模块能力建设；
PaaS 服务层：提供搭建编辑器的运行环境，使其能具备有完备的搭建配套服务能力。
研发中心层：业务研发的主阵地，提供云端一体化的研发流程。包含站点中心，应用中心，物料中心，数据中心 4 个功能模块。
搭建产品：最上一层是搭建产品层，是 iceluna 作为 PaaS 平台或中台，目标孵化的各个垂直领域的搭建产品。

功能模块设计

接下来从功能模块设计角度来进一步了解 iceluna 的功能全貌，还是基于刚 PaaS 角度的架构设计核心 3 个分层来拆解里面的核心模块。

搭建基础设施这层的话，就包括基础能力的建设，包含搭建协议，视觉规范，工程脚手架等源码级别的一些基础能力。其次是我们搭建编辑器内核，包含了骨架、主题包、插件、用于配置可视化属性面板的控件，另外就是我画布和渲染引擎 2 个核心模块，另外还有国际化能力模块。在插件生态模块上，目前整体搭建编辑器上所有的功能模块均是以插件的形式存在。比如在顶部我们会有模型驱动、图像识别、数据驱动、逻辑编排、流程编排等插件，这样一些插件是目前我们重点推广或重点研发的插件，作为研发模式升级提升效率的核心主抓手。其次是编辑器上常规一些的大纲树、属性/事件/样式/数据等插件，在现阶段主要以可视化增强来达到提效目的。在物料生态方面，我们希望构造一个完备的物料生态，通过低代码方式开发搭建组件、搭建区块、搭建模版、组件实例，并进行物料的发布和共享。对于 PaaS 和研发中心模块就不再一一做详细介绍。

研发流程设计

这一页重点介绍 iceluna 研发中心的研发流程设计，主要分 2 个权限角色：

站定管理员：一般由专业业务前端负责，创建站点审核通过后，可以完成站点基本信息、编辑器默认配置、应用默认配置、物料默认配置等信息。该配置讲决定了在该站点下创建的应用主题、搭建编辑形态、以及物料供选池子等。
应用管理员：选择进入某个站点后，可以在该站点下创建应用、创建多分支、进入搭建编辑器搭建页面或组件，在线实时调试，一键发布部署等操作。

中后台搭建基础设施建设

了解了 iceluna 从各个维度的设计，相信对 iceluna 的产品设计有了一个更全面的认识；那么接下来，我们从实现层面，看看 iceluna 建设了哪些基础设施能力，来保障搭建平台的技术先进性。

从这一页内容是我们整个低代码搭建基础设施的一个内容全图，从左侧我们可以看到一个物料研发的流程，由专业前端同学研发源码的物料，并沉淀到物料中心，这样一个源码的物料，通过我们一个解析模块，可以生成一份搭建组件描述文件，有了这份描述文件，就可以入驻到我们的低代码搭建编辑器里面来，低代码搭建编辑器会识别这个组件，生成这个组件的属性配置面板，并具备有良好的搭建编辑体验。其次，编辑器可以将已入驻的源码组件，以发布的方式上行到物料中心，沉淀成为一个搭建组件。多个搭建产品矩阵，基于相同协议标准，与物料中心的上下行，使物料得以流通和复用，从而形成物料生态。从最右侧可以看到，前后端、外包、测试都是通过搭建方式来使用低代码编辑器，低代码编辑器成为了最核心的一块能力。如何保障低代码编辑器的技术先进性，总体建设的思路，从以下 5 个方向阐述：

首先要定义一个搭建描述协议的标准规范，所有搭建产品遵循这套搭建规范，这样可以使物料得以流通。
我们要构造一个搭建编辑器开发生态，iceluna 作为 PaaS 平台或中台提供出来的一个能力，去低成本的孵化各场景下的低代码编辑器；
就是我们提供出来的低代码编辑器，在面向不同端的一个诉求，我们会包含 React，Rax，小程序等技术栈的搭建，需要编辑器能支持多技术栈，适配多端。
相比其他低代码编辑器，它如何保持技术先进性，有哪些核心能力建设。
是我们要打造的插件生态和物料生态。

搭建描述协议标准规范

如何指定搭建描述协议的标准规范？从以下 4 个方面阐述我的一些思考：

版本化、语义化、渐进性描述：版本控制，语义清晰，简明易懂，可读性强；搭建的本质是通过源码组件进行嵌套组合，从小往大、依次组合生成组件、区块、页面，最终通过云端构建生成应用的过程。因此在搭建基础协议中，我们需要知道如何去渐进性的描述组件、区块、页面、应用这 4 个实体概念。
不引入新概念，可与标准源码互转：不引入新的语法概念，代码部分纯 JS 语法，降低上手门槛；明确每一个属性与源码对应的转换关系，可生成跟手写无差异的高质量标准源代码；
可扩展，可流通性，面向多端：支持第三方 npm 包的引入，增强协议描述能力的扩展性，以应对不同应用复杂多变的需求，如 Lodash ，Moment.js 等第三方工具库；产物能在不同搭建产品中流通，不涉及任何私域数据存储，统一标准，构建搭建物料生态。不能仅面向 React，还有小程序等多端；
支持国际化

低代码编辑器开发生态

iceluna 作为一个 PaaS 平台或搭建中台，我们希望把搭建编辑器底层所有的能力都能原子化的开放出去，所以我们在建设搭建编辑器的时候考虑到了以下几个问题：

分层架构：整个框架分为四层能力的建设，最里层为搭建编辑器的内核（主要有消息通讯、状态的管理及配制的解析、骨架的加载、插件的机制的加载等能力）；其次为渲染模块，也就是渲染模块的部分，它的输入就是符合搭建描述协议的 Schema，通过这个模块可以把整个页面渲染出来；再往上为编排模块，主要负责画布区域的物料拖拽、下钻编辑、点击，快捷键，多设计模式等操作，提供了灵活的拓展能力；最上层为整个编辑器的框架，包括骨架、主题以及编辑器里面所有的面板都是以功能插件的形式集成进去的。
模块化解耦：这里的框架分层，每一层均为独立 npm 包，提供原子化服务的能力去开放。比如我们可以以整体低代码编辑器整体开放给需要的场景，也可以只以编排引擎或渲染引擎的方式去开放，如物料中心搭建物料的预览。
扩展能力及开发生态：除了提供现有的能力之外还提供完整的骨架，插件及控件的开发脚手架及命令行工具来保证整个低代码搭建编辑开发机制是完备完善的，同时整个骨架、插件也是可以在我们整个平台进行配制或定制。

低代码编辑器多端适配

目前搭建编辑器面向的领域不仅仅是中后台 React 的体系，还包含有 Vue ，小程序、Rax 的体系，这样的一些体系因为底层的技术栈不同，对于组件的解析和渲染存在较大差异，不能通过纯粹的 React 渲染模块来把总个页面渲染出来。所有呢，我们怎样去适配多端，需要针对不同的技术栈，来实现对应的渲染引擎，通过很薄的一层适配层来使得我们的搭建编辑器支持各个技术栈的渲染，从而达到多端适配的目的。比如，阿里表格数据报表的搭建， imgcook 消费者端搭建，淘宝小程序搭建等。

低代码编辑器核心能力

第 4 块内容，就是我们如何保障搭建编辑器技术先进性的一些核心能力。

开箱即用：提供全链路一体化的搭建服务，不需要到线下去 2 次开发。其次支持定制搭建编辑器和定制业务主题风格。同时在我们平台上支持多人协作、多分支并行开发，可以应对大型复杂工程。比如淘系营销系统，同时会有数十个人并行开发同一个应用，往往会建立数个分支并行开发需求。所以呢，像这样一些大型复杂系统，中后台搭建系统不具备有多人协作和多分支并行开发的能力，那基本上在我们的业务场景上是无法落地的。所以这 2 块能力建设非常关键和重要。
安全沙箱隔离：我们对业内比较多的搭建产品做市场调研，发现较多搭建编辑器是没有做好沙箱隔离的。 iceluna 发展 3 年，反复从做隔离到不隔离几个阶段的不断迭代，最终彻底解决掉所有问题，完全实现沙箱隔离，从而保障搭建页面与编辑器本身完全隔离，互不干扰，并支持独立主题设定。
实时调试能力：我们的画布是一个真实的 Runtime ，它不是一个模拟器或不完整的渲染，业内很多低代码编辑器在搭建状态就是一个纯 UI 的渲染，通过低代码方式配置了交互数据或事件，它无法实时实时生效，需要通过预览或发布等链路才能调试。而中后台场景业务逻辑非常重，往往需要高频的实时调试，这也是跟其他搭建产品不同，是结合业务场景建设的一个重要能力。

低代码编辑器物料生态

我们提供的通用搭建平台，对于不同的业务场景，对于物料的诉求是不一样的。今天，我们的搭建平台服务于 400 多个前端应用，要服务集团 20+ 部门，或者更大的一个组织体系，如果只提供一套物料库，那搭建平台的可用性会因此而大打折扣。我们需要针对不同 BU 不同业务场景，能够具备有快速接入不同物料的能力，第 1 点我们要能快速生产物料，第 2 点能快速接入已有的物料，第 3 点就是能够让这个物料流通起来，能够变成一个生态的机制，就如 Iconfont 图标生态一样。所以 iceluna 也在致力于怎样去打造一个低代码搭建物料的一个生态。我们在这块做的核心工作，主要如下：

统一搭建物料描述协议：统一标准，规范生产，提升搭建物料的可复用性。
实现物料低成本接入：支持 React 组件 npm 包低成本的接入，不需要对组件进行 2 次包装或开发，通过简单配置一个表单，就可以将组件接入进来，并且保障组件在源码里面完整的所有属性，在属性配置面板可以具备完整的可视化配置能力，无论你的属性是什么类型，数组类型也好，对象类型也好，ReactNode 类型也好，都具备有完整的可视化机制，来保障良好的编辑体验。
搭建物料流通：建设搭建物料市场，形成类似 Iconfont 的生态机制。

我们回到左侧图上来看，我们的低代码编辑器，它不仅仅是可以接入组件，最重要的能力就是通过低代码的方式来生产组件，为什么？低代码编辑器面对更广的用户，比如后端和外包同学，他们不掌握很多的源码知识，也不掌握源码的工程体系环境，但是他们同样会有做组件的诉求。其次，搭建编辑器本身就是一个提效的开发模式，无论是前端还是后端，研发页面还是组件，低代码开发同样带来开发侧的效率提升。在 iceluna 上，我们也提供了物料专属的搭建编辑器，可以在我们的平台上通过搭建的方式搭建物料，并且把这个物料上行到我们的物料中心，最后形成物料流通的机制。

提供搭建服务的 PaaS 平台建设

这一章节，回到我们主题的核心重点— PaaS 平台能力建设上来。对于在听的同学来说，可能对于 PaaS 平台的定位也不是特别清楚。PaaS：平台即服务 ( Platform-as-a-Service )，iceluna 的 PaaS 定位是把搭建编辑器的运行和开发环境作为一种服务，提供给不同业务场景下的搭建产品。

前面我们讲到了搭建基础设施是提供搭建编辑器的开发环境，那上层我们还需要一个更加完善的平台侧服务能力，来提供搭建编辑器具备完整良好的运行环境，使得我们具备有一体化研发的能力，在整个能力的基础之上去孵化垂直领域的搭建产品。

我们将从下面 6 个维度来介绍 Paas 服务的能力：研发中心编辑器定制、云端构建 & 发布 & 存储、多人协作、多分支开发、代码回滚、效能衡量。

搭建编辑器定制服务

在我们的站点中心提供了一个可视的方式来进行一个编辑器的配制，通过云端构建就可以构建出不同搭建编辑器，比如右边的 Iceluna 搭建编辑器及下面的 imgcook 编辑器，就是在研发中心创建了 2 个不同的站点，分别构建出来的编辑器。刚我们看到了编辑器的一份配置，那么编辑器具体可以配置哪些内容呢？

布局定制：编辑器面向的领域不同，场景不同，做消费的页面和中后台页面，它对于面板画布的大小及可利用区域都是不同的，所有我们对于整个搭建编辑器面板布局是有不同的诉求。而我们可以通过这个的一个布局定制来快速构建出不同的布局出来，再配制不同的插件可以形成一个全新的搭建编辑器。

主题定制：搭建编辑器可以嵌入不同的场景，比如在淘系里面我们可嵌入 WebIDE 跟源码进行一个互转能力的打通，你可以同时切换到源码的开发，也可以同时切换到可视化的开发，在 WebIDE 的下面，它整个视觉风格就是个深色系，所以我们在平台上面也提供了主题包配制的一个能力，然后再适配不同主题风格搭配来定制编辑器。

插件定制：我们提供了一个完备的插件化机制，整个搭建编辑器上的所有面板都是以插件化的形式来承载的，目前 iceluna 编辑器上总共有 26 个插件（图右可视），同时在插件生态池子里面，我们往后会沉淀越来越多的公共插件，并且这个插件都是可以被嵌入到搭建编辑器里面的。如果这个插件池子里面没有你想要的插件，我们也提供了插件开发脚手架，给你来实现与编辑器功能解耦，可插拔，可定制的一个独立的插件。

云端构建/发布/ DB 存储服务

云端构建服务是 iceluna 低代码开发平台核心链路之一，目前云端构建的能力主要是把我们在应用搭建过程中搭建出来的页面，然后组件产生出来的 Schema ，存在数据库里面之后的碎片化数据，通过云端构建的方式，去发布成应用或组件或者编辑器资源包，同时构建出来的这些应用、组件它们的源代码，我们也推送到 GitLab 作为存储，也会发到 CDN ，申请 CDN 资源最终推送到线上去。目前云端构建主要支持应用（日常/线上发布）、组件（Low code/ Procode发布)、编辑器（画布/框架的构建）3 大功能 6 种形态构建能力。

云端构建架构图分为数据层，运行层，通信层，应用层4层，如图左所示。它的核心能力主要包含如下：

编辑器去中心化：在我们的平台，站点下创建的每一个应用均对应一个自己的编辑器资源包，这样的话，我们可以给每一个应用去定制自己的主题和组件的扩展，并带有版本化控制的能力。
一键发布部署：进行权限管控；对组件的依赖进行动态分析；在分支发布过程中会需要合并主干，如果产生冲突的话，在线解决冲突；Webpack 构建和 CDN 发布。
多系统打通：GitLab 存储以及通过 GitLab 来做代码回滚的机制，其次通过 Tair 做构建过程的并发锁，最后，通过 ODPS 做构建日志的分析。

多人协作服务

在 PaaS 平台，多人协作是一个不可缺少的一个能力，它的主要原理是通过 WebSocket 的连接加上一个文件锁的机制，文件锁目前在平台上包含页面锁、组件锁、应用级别公共文件锁这三个维度的锁。大体思路主要是利用WebSocket 的保活的机制，与 Tair 保持一个心跳保活的消息通信。在 Tair 侧则是存储一个主动失效的分布式乐观锁，然后去存储这个锁的信息，大概 10 秒钟之内没有新的心跳过来，这个锁就会失效。所以说一旦客户端或 Server 端的 client 断了之后，那这个文件锁就会被自动释放这样一个机制来做的多人协作服务。我们也对业界多人协作的方案做了一些调研，比如钉钉文档、Google Docs 等都利用了业界比较先进的 OT 技术，实现相对复杂，功能也更强大。对于低代码搭建编辑器场景来说，编辑锁的能力已经够用了。左侧 iceluna 编辑器上红线框出来的点，都是有锁的功能。

多分支并行服务

多分支并行的能力最重要解决的一个问题是冲突解决，对于源码来说，冲突解决是已经存在的一个能力，但对于低代码云端工程体系来说却是一个非常难解决的问题。截止目前为止 iceluna 冲突解决的代码仍然是搭建描述协议 Schema 的代码，比对时相对比较困难，这是问题之一。其次，总个冲突解决的流程，多分支并行，包括代码回滚到数据库 DB ，这一块总个机制的构建也是相对比较复杂的。总体的流程如上图所示。

代码回滚服务

代码回滚服务主要利用的就是基线同步的机制，这个机制保障我们可以指定任意 commit hash 进行编辑器应用代码回滚。因为我们在低代码平台的每一次发布，都会将代码同步到 Git ，所以任何一次发布的代码都可以回滚到我们的低代码编辑器。这里最大的难点就是 “ 数据库的碎片化信息 ” 与 “ Git 仓库上源码工程文件 ” 能具备有一一转换的关系。

搭建效能衡量体系

最后一页内容提到了低代码搭建平台的效能衡量体系，其实它跟技术不太相关，但为什么要讲效能衡量这个体系呢？我们在做搭建平台 3 年，还有其他兄弟团队的搭建平台都面临一个问题，就是都说搭建能提效，但没有一个很精确衡量提效多少的方法或策略，所以我们花了很长时间去研究，怎样有一个策略来衡量搭建是不是真的提效了。具体的实现方式，衡量标准是我们借助业界霍尔斯特德软件复杂度测量算法模型，这个算法模型可以将搭建页面时产出的 Schema 作为一个输入，它通过 Schema 里面的如表达式个数，代码长度等数十个算子，可以计算出 Schema 的复杂度以及预计开发时长。

当然，这个预计开发时长需要反复去调参，比较符合真实情况后会得到一个相对准确的数字。另外呢，低代码搭建相对于源码开发，有一个好处就是用户都是在我们的平台上进行操作，平台侧可以通过埋点，操作日志等手段记录每一个研发人员在某个页面上的操作记录，在 2 次操作间隔时长在 10 分钟之内的算有效开发时间段，有效时间段的总和就是实际开发时长。通过计算公式研发效能 = 预计开发时长/实际开发时长就可以知道该用户开发效能是提升还是降低。在 iceluna 平台上数据中心会有专门一个效能中心，来反馈总个平台的总体人均研发效能、个人研发效能等数据。所以说这一点非常有价值，所以分享给大家。

总结&展望

前路总结：中后台通用搭建产品建设成本超高，能很好的解决赋能&协作的问题，但研发提效未达数倍甚至 10 倍的预期，需要往模型驱动、智能搭建等 Nocode 新研发模式升级，或建设领域搭建产品矩阵来达成数倍提效的目标。
展望未来：致力于将 iceluna 打造为中后台领域的 hpaPaaS 平台（超高生产力平台）。如果志同道合，期待的你的加入！