积木系统上线半年，取得了些成绩，也暴露出不少问题，加上 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. 更易定制的、易于业务优化的编译、打包系统。

想让 markdown 高亮，找了点插件，比如

https://github.com/jonschlinkert/sublime-markdown-extended

可以让代码块高亮。但没有达到我想要的效果，我想让 markdown 的每个部分高亮，比如 # 标题 高亮。

然后找到了

sublime-monokai-extended

这个达到了我的效果，但是将整个的 color scheme 都改了，自然不行。

现在的问题是——

在当前的 color scheme 高亮 markdown

继续寻找，然后找了这个

markdown.xml

按照上面说的，将代码复制到我的 Obsidian.tmTheme ，成功了。在现有 color scheme 上高亮了 markdown 。

但是头疼的是，我不喜欢他的 标题 颜色，想改。看了代码，摘录一段：

一头雾水，完全不知道 how does it working ，也就无从改起。

没有解决不了的问题，找了半天，这篇博客

Tips For Creating Sublime Text Color Schemes

解决了我的问题。其中的 tip1 尤其好——

Sublime text color schemes work by defining colors for scopes. A syntax definition matches the different parts of the file’s text (e.g. functions, classes, keywords, etc.) and maps them to a named scope. Then the color scheme specifies what colors to use for what scopes.
The hard part comes when you see a particular piece of syntax you want to style a specific way, but you do not know what scope it is. I did a lot of guess work until I discovered the ScopeHunter plugin.
The ScopeHunter plugin allows you to select some text and it tells you what scope it matches. This removes the guess work and allows you to quickly color the pieces you want to.

sublime text 的 color scheme 是通过 scopes 来定义 color 的，我们可以安装插件 ScopeHunter 来查看光标出的 scopes ，从而可以自定义颜色。

至此，已经可以修改 markdown 到我想要的状态了。但是我又想，能不能把 markdown.md 的背景也改了，
甚至模仿 github 的样式。

少说多做，幸福一生。

马上把上面的代码加入 color scheme，有效果，嗯，现在比较大的问题是 lineHighlight（鼠标所在行高亮）比较突兀。

是个问题，并且 lineHighlight 没有 scope ，蛋疼了。

解决方式是调整全局 lineHighlight 的值，使其用透明度达到效果。

Perfect!

参考：

http://stackoverflow.com/questions/10636410/modifying-sublime-text-2-for-js

附上我的 color scheme Obsidian.tmTheme ：