积木系统上线半年，取得了些成绩，也暴露出不少问题，加上 2.0 版本也准备开动，因此正是时候来个总结反思下。

项目开始之前

系统要解决的问题

产品运营在产品侧来说，是个大事，产品的冲量、用户的活跃等等一大堆指标都靠它了，有人说再好的产品不运营也是个渣渣。于此同时，产品运营对技术岗的同学来说，是无休无止的赶时间点（节假日、网络热点）以及不是很能体现技术含量的重复性的简单页面。

这个矛盾，让产品和技术双方都很沮丧，产品觉得技术不够重视，技术则觉得不应该在重复性的简单的工作上投入过多时间。

好吧，这其实就是积木系统想要解决的问题以及终极目标，让产品同学可以快速发布页面，同时技术同学沉淀组件（积木）来避免重复性工作，如下图：

系统的核心功能

分析了各方的痛点以及诉求之后，系统的核心功能其实和容易理出来：

• 简单易用的、可视化的可编辑页面
• 通用的、简便地组件接入机制

当然除此之外还要有：

• 发布系统，既然是批量的生成页面，也就没必要每次都有测试（首次发布要严格测试）来发布
• 编译系统，类似 grunt ，fis 做的事，发布之前要编译，如果资源合并、CDN 路径替换等等
• 业务管理系统，是的，这个系统不能只为腾讯课堂服务
• 权限系统，不多说
• 响应式，一次配置，多端运行
  ……

开始技术规划之前，我们有必要也必须要分析现有的解决方案，没必要重复轮子。

现有的一些解决方案

传统的后台管理系统（CMS）

不管是产品还是开发，对 CMS 应该都不陌生。

技术开发好前端页面以及后台录入系统，产品在录入系统录入和修改数据让后发布。

这个方案离我们的期望很远：

• 不能可视化的编辑页面
• 页面的路径都不容易变动，而我们的活动则是无穷多个
• 前端代码倒是可以组件化，但也也就停留在代码层面，而不是系统层面

毫不留情的 pass 。

mmrp

这是一个优秀的运营系统，地址 http://mmrp.oa.com/ 。

官方团队这样描述它：

MMRP全称是The MultiMedia Release Platform，数字多媒体内容发布系统。
它是一个全新理念的运营需求处理系统，通过B/S在线绑定数据及前端代码，录入模块库并通过按需求组合组件，生成网页发布到CDN服务器群，旨在推动过渡到工业化时代，避免重复劳动，节省人力资源成本输出价值最大化，同时减少版本风险，缩短研发周期，统一视觉表现。

是的，这是积木系统的前辈，运营系统的先行者。但我们在做深入分析时，也发现了一些缺陷：

• 交互复杂。产品可以在页面拖拽组件，还可以给组件绑定事件（比如 click），多个组件的之间的联动等等等等。这些操作我作为一个开发者在使用的时候都有些云里雾里，不要说产品了。产品在这里的诉求是简单配置，快速发布，绑定 click 事件什么的真的有些夸张了。
• 难以维护和移植。组件和系统是耦合的，这一点很致命。没新增一个组件，系统都要做相应调整，这对于多业务的系统来说是不可介绍的，假如我们的 tapd 也是每新建一个项目就得改下系统……太可怕了！

上面的缺陷，丝毫不影响 mmrp 的光辉，虽然它已经停止维护了，但还是要向它致敬！

积木系统的设计

现有的系统并不能满足刚需，所以，积木系统蓄势待发。
经过团队（imweb）几轮的讨论，架构如下：

可视化和组件化摆到了核心位置，也对应了积木系统的两大核心：系统本身和组件体系。

系统：

• 可视化编辑
• 发布
• 接入各种组件

组件：

• 开发过程和系统无关
• 逻辑和系统无关
• 遵照系统约定

系统不求花哨，但求实用。更多的细节有时间在单独来篇文章，这里就不赘述。

取得的成绩

接入的业务

• 腾讯课堂
• QQ 电影票

发布的活动

总数将近 50 个，其中响应式 30 个。响应式如果走开发流程的话，工作量翻倍。
换算成工作量 (20 + 30 * 2) * 3 = 240天。这是保守估计，一个活动算了 3d 工作量，同时这也仅仅是算了前端开发，没有算上后台、cgi 、视觉等等。

存在的问题以及 2.0 版特性

问题同样不少，比如接入其他业务还是不够方便、组件与系统联调也不是非常简单，为了解决遇到的问题，让系统更容易接入、开发和移植，积木系统 2.0 已经在规划中！

2.0 的新特性包括但不限于以下几点：

1. 系统和业务分离，业务逻辑以插件的形式接入系统，方便业务接入。
2. 组件开发套件，无需搭建系统来 debug 组件。
3. 更多的表单类型支持，这里的表单是编辑页产品配置表单，包括单选、多选等等常用表单，颜色选择器优化以及能展现复杂数据结构的组件 型表单。
4. 更易定制的、易于业务优化的编译、打包系统。