我们从工程的视角来看，“大量紧急不重要的页面”，才是真正的需求，现在需求有了，我们就应该按照工程的方式，定目标、设计方案、做实施、拿结果来解决问题。这就是我们今天要讲的搭建系统。
搭建系统的目标是解决大量的简单页面生产问题。衡量这个目标的指标应该是生产页面的数量，这部分非常的明确，你如果要做搭建系统，可以根据业务的体量和服务的范围来决定具体的指标要求。
第一种，是模板化搭建，由前端工程师生产页面模板，再由运营提供数据来完成页面，可以用以下公式来理解：模板 + 数据 = 页面 第二种思路是，模块化搭建，由前端工程师生产模块，由运营把模块和数据组织成页面。 第三种思路，是数据驱动界面，这是一种比较新的思路，即数据中包含了展现自身所需要的模块相关的信息，本身决定了界面。
数据是用于展现界面所需要的信息。 我们按照数据用途，可以分成界面配置数据和内容数据。
- 界面配置数据：决定了页面上颜色、尺寸、位置、图片、文字等展现形式的数据，通常是以页面为单位的配置。
- 内容数据：页面要展示的信息，如电商活动页面的商品信息、文章的文字信息等。
按照数据来源，我们又可以分成运营人员手工填写的数据和来自API产生的数据。
- 运营手工填写固定数据：运营人员依靠自己的专业技能决定的数据，可能包含线下招商信息、商品选品、文章等。
- 来自API的数据：
- 固定数据，由服务端逻辑到指定存储处获取的数据；
- 用户相关数据，由算法系统或者服务端逻辑，根据用户信息或者用户喜好推荐的数据。
搭建系统本身是个产品，我们针对数据这个实体，要设计增、删、改、查的能力，根据我们以上的分析，搭建系统的数据部分有两个难点。 第一个难点是数据的手工编辑能力，现在一般的数据都会采用JSON格式，JSON格式中有数字、字符串、数组、对象、布尔等数据类型，我们需要根据数据的格式定义为每一种类型设计编辑器。 实际开发中，还需要跟实际业务结合来设计编辑器
- 整数：整数编辑器，可用HTML原生输入框
<input type=number min=1 max=100/>实现。 - 数字：数字编辑器，可用
<input type=number min=1.0 max=100.0/>实现 - 字符串：字符串编辑器，可用
<input />实现。 - URL：URL编辑器，可用
<input />配合格式校验。 - 固定字段对象：对象和字段编辑器，可用多个
<input />和<label>实现。 - 布尔型：开关，可用
<select>或者自研组件实现。 - 自由字段对象：需要自研KV输入组件。
- 数组：需要自研列表组件实现。
- 对象数组：需要自研表格组件或者列表组件实现。
- 矩形区域：需要自研区域选择组件。
第二个难点则是跟服务端API的对接，对于服务端系统统一性较好的公司，这不是什么难事，对服务端系统比较奔放的公司，如果服务端API调用方式不统一，就非常麻烦了。这一块只能根据实际情况见招拆招。
模板可以简单得理解成挖了许多坑的页面，它一般是由前端工程师来生产的一种实体。与数据之间的连接是数据的格式，对JSON格式来说，JSON Schema是社区接受度较高的一个方案。
最简单的模板可以用字符串模板来设计，复杂一点的模板则可以由JavaScript进行渲染，通过约定全局变量名称或者约定调用函数入口做到把数据传递给模板，你可以根据实际需求复杂程度选择合适的方案。
需要注意，在产品设计上，模板可不是“增、删、改、查”那么简单，考虑到实际工程需要，模板必须是版本化的，也就是说，前端每发布一个模板，都需要永久性存储一条记录，并且产品设计上必须保持可以回滚，这样，一旦线上发现问题，可以迅速回滚到一个可工作的版本，有效降低不可用时长。
此外，模板设计还有批量更新的需求，一些运营活动可能包含数百个页面，它们使用同一套模板，产品设计上必须要注意提供批量更新机制。
模块跟模板非常相似，但是从产品的角度，模块是可组合的。跟模板相似的部分如数据连接、版本化发布、批量更新等
不论是模板搭建还是模块搭建，我们的最终生产的目标都是页面。页面同样需要版本化发布，便于回滚。
作为一个工具型技术产品，搭建系统同样会产生大量有价值的数据，搭建系统的用户访问和生产页面数量是衡量自身的重要指标。