谈谈前后台协议

Posted by Masutangu on November 3, 2015

最近在做一款内容型的app,身为一枚后台开发童鞋,在开发新的功能的时候,初期总是需要制定和客户端的协议。在绕了不少弯路后,今天在这里总结一些经验,也算是一种沉淀。

制定协议最主要就是灵活,通用。针对一款内容型的app,你可能会有很多个页面,展示很多种元素,每个元素会是不同的类型。我们拿一款fm的app来做示例: app示例

如果我们要开发上面这三个页面,你会怎么制定和客户端的协议?

我们先来简单分析下。精选页有banner/新闻栏目/音乐栏目等。各个栏目下的元素是专辑,展现形式为一行三个专辑。电台页有地区/分类/正在直播。地区和分类的元素是分类,点击可以进入到该分类下的电台。正在直播的元素是电台,展现形式是一行一个电台。小说页有banner/神推荐栏目。神推荐栏目下的元素是专辑,展现形式为一行一个专辑。

可以看出,这三个页面虽然看起来大不相同,但其实本质是一样的。每一页(Page)由一列列(Column)构成,每一列可以有banner/栏目/分类这几种类型。每一列可以有一行一个/一行三个这些展现形式。每一列内可以有专辑/电台/节目/分类这些元素(Item)。每一列可以有不同的点击事件(跳web页面,跳更多页)。所以,这三个页面可以通过一个通用的协议来表达: 协议示例

这样如果需要再开发一个新的页面,就无需再操心和客户端费心思去定一个新的协议。同时这样的协议非常灵活,客户端ui的展现和点击事件完全由后台来控制。

这样的例子看起来很简单。但是在比较大的团队里,要做到协议的通用还是比较困难的。因为每个人会负责不同的模块,极有可能你只关注到自己做的那个模块,设计出来的协议可能只适用于你自己。要如何规避这种情况呢?这里我提下个人粗浅的观点:在app项目启动的时候,团队首先对app样式上整体有个粗略的规划(可能会有哪些页面,向用户展示什么信息?),汇总出一套模版。每一个app都是由各个不同的页面构成,尽量去抽取出各个页面的共性。内容型app就非常明显,各个页面再怎么变化,都是由元素+展现形式构成。制定像上面这样的通用协议,大家的开发都基于上面的协议,有需要再去扩展新的元素类型/新的ui。这样整套协议非常清晰,同时减少前后台沟通成本(大家对通用的协议都很熟悉,规则也是固定的),能够提高开发的效率,减少重复劳动力。