让代码配置化

背景

面对运营频繁的页面修改,每次都是换个图,改个字,要么就是在现有的页面基础上新做一个,再稍微的改点东西,虽然这种需求做起来也不是很费事,但也架不住一天一次修改(有点夸张,但的确很多)。日积月累,就开发出很多相似页面,大多数都用作abtest,在众多页面中选出个别页面,其他页面只能被打入冷宫,永远没有访问的机会。显然这些页面留在项目中额外增加了打包编译负担,甚至拖累其他页面速度。

原来

日常开发流程是这样的:

开发 -> 合代码 -> 上测试环境 -> 测试 -> 合代码 -> 上uat环境 -> 测试 -> 合代码 -> 提发布申请 -> 发布 -> 验收

就算是一个3分钟搞定的需求,流程也需要1天,因为中间有太多的环境切换和人员流转。

这样的经历所有做过运营活动的童鞋或多或少都有体验,所以很多人也想过做一个编辑器,比如拖拉组件的方式实现一个页面。

我们曾经有种设想是直接给运营做一个活动编辑器,让他们自己去修改,自己去做页面,自己发布。说实话这个也做过,但是没用起来,原因呢大概就是人性的贪婪与懒惰,当初做出第一版的时候觉得太简单,不能满足使用需求,第二版的时候功能倒是挺丰富,但是运营又不会用。想想那么多css样式,你以为图形化了他们就会用?太天真!干脆教他们写代码好了!

现在

所以这个项目就夭折了。本文演示的是一个将代码配置化的平台。期望解决的是代码冗余,但同时也有效率的提升。 这个平台最终流程变成了这样:

开发 -> 测试 -> 发布 -> 验收

是的,由原来的11步直接变成了4步,其中开发发布也比原来更简单了,你可以选择自己喜欢的编辑方式和开发框架,或vscode,或devtool,或工具提供的文本框,或jquery,或vue。可单独对css,js,html修改,将修改的内容直接提交即可看到效果。 为什么会减少这么多?因为没有了测试环境和uat环境的流转,直接在生产环境操作的。

是不是会有疑问——直接在生产环境开发会不会有风险? 答案是:不会!项目本身是分为两个环境,一个是开发环境,另一个是访问环境。开发环境是用于内部开发和测试使用,不对外开放,只有发布后才将开发数据同步到公开环境。

编辑器演示

上图展示的是一个示例程序,提供一种思路,可根据自己需求开发相应功能。比如支持多环境发布,回滚,都可以做到点个按钮就行,不需要等待编译和重启等耗时。因为开发完成后的一切操作都是数据的操作,并不会涉及到编译,所以无论是发布还是回滚都是毫秒完成。 这种做法适合频繁修改的页面,万年不变的页面就不需要这样做了。

核心思想

这个项目的核心思想是将代码做成配置,我们都喜欢做配置平台,让业务来操作数据省去了修改代码,为什么不可以将代码也做成配置?