随着产品的不断迭代，功能的不断完善，我们的项目的中会给用户分成区域呈现出越来越多的东西。咕咚的精选给用户一种信息广场的概念，让用户可以快速的抵达我们感兴趣的点。既然如此，那么每一个项目的综合信息的页面经常会被改动。出现位置的调整，出现新的模块的增加，出现模块的删减等等。那么我们就一定要思考我们该如何构建我们这一部分的代码，在一次次的更改后可以用最短的时间完成产品的需求。最大限度的提高我们的工作效率。
下面我们通过咕咚的精选页面来思考一下具体的实现思路
我们看到这个图片的时候先思考一个问题，这么多个分区到底有多少请求接口？ 有小伙伴可能说这不是一个接口完成的么？ 然后变成一个很复杂的json返回给客户端，然后在慢慢的做解析，我想这样的做法，这个界面每一次更改服务端和客户端都要经历一次代码的拆分，要改很多的东西，这对于两端的开发人员一定是不友好的，我也顺手用charles抓了咕咚的包，验证了我的想法，他们这个界面确实是多个接口组成的。那多个接口能给我们带来什么好处呢？
现在请大家思考一下，如果产品会在下个版本中添加一个模块，调整两个模块之间的顺序，之后还会删减部分模块，甚至出现改变多个分区的顺序的情况的更改？我们如何做修改才能最大化的减少我们的代码逻辑呢，减少我们的工作量呢？
我们的项目最近在做相似模块的重构，我的tableview界面现在每一个分区的位置完全可以根据运营的数据在服务端进行动态的调整位置，可以根据运营的数据，在不改变客户端的代码的情况下动态的去删除一些模块。这又是如何完成的呢？
这里我做的一件事就是动态的绑定 ，我给每一分区的数据整体添加一个固定的identifier此外服务器返回给我一个数据块的排序，我通过这两点生成我tableview的数据源即可。下面是部分实现代码 ，最近我也会写一个小demo放在github上分享给大家，一起高效的完成我们的工作。
首先是请求代码，当然只是伪代码，希望大家主要去了解一种解决方案和思路。使用dispatch_group并发多个请求 在所有请求完成之后完成界面对应的刷新的工作。
将每一个部分看成一个请求即可，我们会把每一个模块的请求结果缓存在本地，下一次请求的时候如果此时数据请求失败，会从本地读取上一次的数据。然后我用伪代码来写一下我和服务器之间约定的返回的基本形式
每一个请求服务器在返回的数据格式中都会告诉我这三个数据。这三个数据就为我模块顺序调整和动态删除的关键。这个时候我就先使用适配器模式给每一个返回书籍模型添加固定属性identifer，因为请求数较小我就用了快排的方式将返回的数据转换成数据模型后根据sort和isUser两个维度创建了我tableview的数据源。
这样在tableView中我们看到的形式就变成了下图的样子 我们完全可以根据identifier动态的去部署我们的每一cell 同理可以设置高度等相关的内容 ，这个大致思路就是如此，最近会写一个小demo，有这个整体一些的代码。
