2019独角兽企业重金招聘Python工程师标准>>> 
通常开发套路
通常公司进行app开发，都有会以下2个必要的组件（我是后端）：
1、server提供接口
2、根据ui，移动端设计界面并渲染（动态数据由接口请求返回）
这会产生什么问题呢？
由于国内的环境，大家懂得，开发迭代的速度会非常快，通常一个ui上周说是要这样，这周就要另个一个样子了。
但是，由于客户端的发布和打包审核都有一定周期，导致项目无法准确在准确的时间点上线，所以最好是能由服务端来控制，我到底使用哪个UI进行渲染和操作，会大大加快版本迭代，也可使前端开发更专注在ui的适配性上。
文章背景
目前我就职于国内W公司，马上就要进行离职了（回家种地！哈哈哈），所以想把一些已知的东西做些记录。
w公司，嗯，国内也算几个最活跃的app之一了。那W公司是如何快速进行业务开发的呢？
W公司客户端套路
W公司的每个客户端页面都是一个page，然后里面是card。以图来解释吧：
所以，客户端前期的工作就是渲染大量的card。
而到了后期，只用迭代主ui和交互工作的scheme即可。
W公司服务端套路
W公司的业务是繁重的，每个业务之间几乎有天差地别的处理，那对于客户端来说，他不可能去每个业务方单独调用每个接口，因此，要有一个中心，W公司称之为(mapi 微服务的api getway部分)。
然后业务线很多，每个接口参数也不一样，这时候，假如业务方每次更改，都得和mapi同步信息，好像也不好。因此，衍生出一个对象库(object library)，按照我的理解，就是每个要渲染的对象都拥有唯一的一个id，每个id在对象库里都存在着相应的业务。
同样，以图说话：
请求过程： client->mapi->objcet->modules->mapi(汇总数据)->client
对于每个业务方: 写接口->注入到object->将oid注入给mapi
这样做还有另外一大好处，就是可以充分的解耦每个业务方（当然也有不好的地方，每个业务方实际都是自己维护自己的数据）。
当然，图中并没有提及W公司的核心业务feed，因为我直接想总结下这个套路。
套路的思想
其实，每个公司都有适合自己公司开发的套路。我在这里总结的W公司的，但是可能并不适合别的公司（我觉得，特别是业务快速迭代的公司不要使用这个套路，前期开发成本太大，当业务定型之后，可以根据这个套路进行更符合自己业务的调整）。
文字不太会总结，所以我通常都喜欢以图说话 emmm.