Project Description
For the needs of users at different stages, we have excavated diversion value Yuesao service type, make recommendations in more APP entrance, access to revenue diversion, resulting in Yuesao project
Technical Solution Selection
Can be selected when the project started, there are two technical solutions
1. expand the program based comment system, by way of new module development
2. The program opened a new warehouse project Yuesao to butt the way for development
After and product manager, technical director of various tear force, chose a plan for the following reasons
1. The amount of development
program to develop a relatively less number of
do more docking comment system (reducing the time to write the SDK)
without redeploying development , test, gray, online environment
without duplication of development basic system functions
2. time
project development time is always a need to incorporate considerations, product manager idea is that demand is very simple, I hope within a week developed, were measured mention
O ( ¯)¯ ) O, 1000W words can not describe Tucao
3. operators operating
operators do not want too much of the background, because the current operations-oriented management background too much
Xiao Bian do not know what a background operation, management background too more, bad management
Needs Assessment
开发工作需要主要分为几个模块：点评管理、派单管理、数据统计、商家中心、前台页面、系统对接
其中参与人员：月嫂项目后端、商家中心后端、前端、设计、测试
月嫂项目后端评估耗时：192h
商家中心后端评估耗时：16h
前端评估耗时：64h
设计评估耗时：72h
测试评估耗时：53h
模块截图如下，具体的就不截了
开发编码
编码的过程中，这里主要来说说遇到的一个主要问题：首页列表推荐
产品提的需求是：
1）推荐商户和月嫂评价信息交叉显示，以10条数据为一页,第1,2条为月嫂评价，第3条为商户推荐，之后每隔5条月嫂评价信息显示一条商户推荐信息
2）排序要求：用户所在城市->后台推荐排序->所在省份其他城市->后台推荐排序->除了所在省份城市的其他城市->后台推荐排序
3）月嫂的服务区域跨市，跨省时，列表上的数据需要去重
第1）需求和广告系统的实现有点像，商户信息就像是一条广告，穿插进月嫂评价列表里面
常见的解决方案是提供两个接口给前端(商户接口，月嫂评价接口)，由前端来穿插商户推荐信息到月嫂评价列表中，最终渲染出首页列表,为了减少前端的开发量，把业务逻辑全部封装在后端，前端只负责显示数据
这里采用了另一个解决方案：列表数据穿插由后端封装，提供一个首页列表接口
列表数据穿插时，这里会产生一个问题：分页获取时，商户推荐信息在列表的位置不是固定
第一页，第3，9条数据是商户推荐信息
第二页，第5条数据是商户推荐信息
第三页，第1，7条数据是商户推荐信息
第四页，第3，9条数据是商户推荐信息
...
从上面的商户推荐信息的位置来看，可以看出如果以30条数据为一行的话，商户推荐信息才会固定下来
但是需求是以10条数据为一页，撕不过产品，所以这里产生了一个“基本页”的概念
一个基本页有30条数据，以3为基数，当前请求页数对基数求模，得出当前页数对应的基本页数
每次获取数据的时候是获取一个基本页的数据，再获取当前基本页数的数据
第2）需求由于月嫂业务是面向全国多个城市，每个用户所在城市不同，按正常的分页查询实现排序是很困难的
这里采用的是分级查询、逐级获取的方案
①用户所在城市->后台推荐排序
②用户所在省份其他城市->后台推荐排序
③除了所在省份城市的其他城市->后台推荐排序
跨级获取数据时，获取完①的数据，开始获取②的数据，这里会产生一个问题：在获取②的第一页第一条和获取①的最后一页最后一条数据之间，
月嫂评价数据的条数会可能会有2,3,4,5,7条数据，这种情况只会出现在跨级获取数据第一页数据的时候会出现
后面和产品沟(撕)通(逼)过后，产品觉得这能够接受，所以这种情况就不处理了
现在想想，如果需要处理的话，可以考虑使用redis的zsortset进行处理
第3）需求由于月嫂是可以有多个服务区域的，所以在查询数据的时候，会出现重复的情况
由于打开首页列表浏览信息是不需要登录的，所以没法拿到用户信息，那这里只能使用session进行去重了
测试反馈
测试开始进场，测出了xx个bug，这个时候只能微笑地修改bug
自己为这个月嫂项目共贡献了10个bug
性能优化
项目上到线上，试运行了两天，产品说这首页列表的性能不行，太慢了，受不了，然后看了下浏览器的控制台，请求首页列表接口居然用了1.8s
首页列表接口需要进行优化，从哪里下手优化呢？哪里导致慢呢？是查数据库太慢了？
该用性能测试工具的时候，这里推荐xdebug+webgrind工具组合
这里推荐一篇很好的博文(https://www.cnblogs.com/xjnotxj/p/6233614.html)
经工具进行性能测试后，发现导致性能问题的主要问题不是数据库，而是curl内部大UC系统获取用户信息慢，其次才是数据库慢
找到导致接口性能的问题所在，采取了以下几个措施：
①大UC接口换成可分批获取头像接口，并且使用redis缓存用户的头像
②请求大UC的用户信息使用redis加缓存
③对评价数据表、商户数据表分别加索引
④对基本页的数据使用redis加缓存
经过上面的4个措施，发到线上，请求首页列表的时间剧降(1.8s➢➢➢400ms)，性能提升了140%
产品测试过后，满意度100%
技术主管测试过后，满意度80%，表示希望优化到200ms以内
如果需要把最后这200ms进行优化，从性能检查工具上看，
需要把基本页和分级查询这两个复杂的业务逻辑简单化，也就是把部分逻辑移到前端处理。
又和产品、技术主管谈（撕）论（逼）一番后，得到的结果是先上线运行一段时候后，如果还有性能上的要求的话，再进行优化
项目心得
① 做这个项目总体来说还是很流畅的
In the pre-project put technical solutions, task split the job done, the process behind encoded in one go on the
② due to the collaborative development and others, in terms of communication also have a lot of skill.
When assigning tasks to others, to explain in a simple understandable way possible assigned task, especially in the band intern, lack of practical experience of junior programmer time.
Description of the task, given your plan and guide the thinking of others connected to their own thinking.
On how many programs should be given to this issue, and different people have different standards of communication
⑴ and product / technical director of communication, then, to give a number of options for them to choose
⑵ actual development and communication, it gives a program like (mainly taking into account the actual developers would have been wandering in the selection, which ultimately did not achieve the program), of course, encouraged him to think there is no other solution
③ in the development of more complex logic interface, it is necessary to evaluate the performance will go to what level, whether it can meet the standard, provide development tools make good use efficiency (xdebug + webgrind)