前言

说到页面可视化搭建，先引出2个问题，后面有机会再补充：

1、页面可视化搭建是什么？
2、页面可视化搭建到底要解决什么问题？

页面可视化搭建是什么？

顾名思义，可以分两部分来看：页面 + 可视化搭建

• 页面： 是最终结果，也就是在浏览器或App里展现的界面。可以是一个普通的网页，也可能是原生的App界面
• 可视化搭建：通过拖拽或点击等交互方式完成页面布局，直观的修改配置并发布，实现 页面 功能一种新的方式。对应的是传统方式，一行一行垒代码，然后构建编译、部署上线(发版)等

页面可视化搭建到底要解决什么问题？

开始之前，先补充几个自己对一些概念的理解：

组件: 对数据、方法、试图的封装，以代码形式提供能力。通常在代码编辑器与其他代码组合一起使用，依赖工程师搞定

积木: 可视化搭建方式的基本元素，符合一定规范，以可视化的方式提供能力。可以是组件和代码的组合，下文提到的积木均代指此

渲染器: 积木运行环境，为积木展示、积木间交互等行为提供底层能力，提供给最终用户使用的能力

设计器: 可以对积木进行拖动、点击、配置等操作的环境，可以看出设计器内部是需要渲染器的

说到底可视化搭建只是页面的一种实现方式，也就是通过写代码的方式都能搞的定，就好像搭积木，没有积木何从谈起搭建，而积木的背后就是一行一行代码的抽象和封装。表面上看只有GUI工程师(Graphical User Interface 图形用户界面，常见前端、iOS、Android工程师等)才会关注，实际上通过底层的封装，提供灵活、简单的配置，就能实现想要的功能，一部分工作也会被无形转移到非GUI工程师，比如后端、产品、运营，甚至普通用户。

注意: 积木之所以能运行，在于有积木运行的环境 渲染器 和配置积木的 设计器，并且积木的实现还应符合一定规范

那到底要解决什么问题呢？

第一、应对业务快速变化

传统模式产出：源代码

• 代码管理：需要代码提交、合并、分支管理等，多人协作开发，可能合并还会冲突
• 打包编译：源码往往不能直接运行，需要编译成浏览器或系统认识的代码，并打包全量代码以方便下一步部署；编译还会涉及编译机器资源、编译环境配置等
• 部署上线：起码需要有线上机器（物理机容器 ），还需要有个启动脚本吧，部署系统必不可少，比如能快速回滚等。据说大多数线上事故都跟上线有关

每一次上线，都需要经历上面一系列过程，中间环节越多、系统越复杂，发生问题的概率就越大，定位、解决问题复杂度越高，对应解决需要的时间也就越长，而且过程中不同系统出现的问题，还需要依赖对应系统的工程师来指导。或许只是想改个文案~

可视化配置模式产出：积木

可视化搭建方式，完成一个页面就不需要上面那些过程，所以对应问题也就没有了。只需要拖拽积木完成布局，配置积木参数，关联积木间关系，直接点击 发布 即可完成上线。过程要比传统发布一个页面简单很多。但是此方式需要一定前提：

• 积木要能覆盖不同的场景，积木种类要多
• 积木本身的实现离不开传统开发模式
• 对积木实现有一定约束及成本，理解如何开发

本质上是通过提供可视化交互方式和积木运行环境，将积木本身可变的部分抽象出来交给用户配置，积木本身的实现仍依赖工程师。也就是哪些参数可变就暴露出哪些，对暴露参数的取舍是个学问，取决于用户有没有能力配置。比如典型用户：

• GUI工程师，工程师自己使用就可以暴露高级的能力，比如可以写一段必要脚本，这样的积木能力也会比较通用
• 运营人员，提供选项、填空的配置形式会更合适，积木的能力也比较有限，一般是为了满足特定场景

也正因使用可视化配置的用户不同，积木的定位也将不同，典型的是运营活动配置平台、流程配置平台、中后台搭建平台等。其核心的设计器、渲染器部分差别并不大，在设计的时候可以将积木设计成可插拔、可扩展即可

第二、GUI工程师人力紧张

解决人力紧张问题方式有多种：招(借)人、砍需求、接受延期、提升研发效率(提升技术能力、提升复用)、工作转移等，这里仅针对 复用 和 工作转移 做下介绍。

复用

• 积木复用逻辑：

这里的复用不是针对不同角色的复用，而是相同角色不同用户、不同系统、不同页面的复用。比如A工程师和B工程师可以用同一个积木，A运营人员和B运营人员可以用相同的积木，不同的页面也可以用同一个积木，当然工程也能使用提供给运营人员的积木，主要在于积木提供的配置项能不能操作明白。

针对不同用户积木对外暴露的配置项不同，比如按钮的积木，工程师需要能配置按钮点击之后可以做什么，需要执行一段脚本，而运营人员只需要配置具体的场景行为，如配置点击跳转的链接，或者显示一个具体提示等。

• 传统模式组件(通用组件 + 代码)复用逻辑：

将业务代码封装成组件确实解决了复用性，但是依然依赖GUI工程师去使用，组件更新不同系统仍然需要在代码里升级，并走构建打包、部署上线的一套流程。积木方式的更新可能不需要做什么修改，之所以说 可能 是因为针对不同场景的积木可以自动更新，可以不自动更新

工作转移

这个词比较容易让人误解，也容易被忽略，工作转移是不是就相当于推卸责任，本来应该工程师做的事，为什么要转给其他人员？

对于上面提到的场景，如运营活动配置平台、流程配置平台、中后台搭建平台等有没有必要，我想大家都比较容易理解前两个，对于第三个中后台搭建平台，往往是GUI工程师或者其他工程师使用，那还有必要么？

如果只有少量的中后台或者工程师足够多情况下，完全写代码当然很好，现实往往不如人意，系统不仅多而且还越来越复杂，工程师越来越像每天重复搬砖的搬运工，除了砖越来越多，也没有成长，一不小心搬错一块，城堡就多了一份风险。

搬砖这么枯燥且累，为什么不能做不同用途的墙呢，在造个车子，谁想建城堡自己来推车子运墙就好了，墙不匹配再造一个便是。肯定有人会问，运墙怎么就比搬砖好了？我想说砖的好坏谁都没法保证，但是砌墙的水泥和方式是统一的，这方面问题可以系统性去解决，也不出现空心砖和实心砖混用情况

第三、减少资源浪费

前面已经有所分析，传统方式开发一个页面功能到上线需要经过很多过程，每个环节都是人或机器资源的投入。可视化搭建方式（这里指web应用）可以在一个统一平台设计配置，最终发布。至于配置好的页面可以通过绑定一个网页地址访问，也可以作为项目页面的一部分功能嵌入，不用单独占用物理资源

总结

• 页面可视化搭建是实现页面的一种方式，通过拖拽或点击等交互方式完成页面布局，直观的修改配置来完成。
• 目标主要是应对业务快速变化、研发人力紧张、资源浪费等问题

关于实践一个可视化搭建，后面有机会针对实际实现的 epage 进行具体分析

如果可以移动一面墙，你还愿意搬砖么？其实，我想要整个城堡。