strick

一、纯手工

  公司主营的是直播业务,会很许多打榜活动,也就是按主播收到的礼物或收益进行排序,排在前面的会有相应奖励。

  纯手工时代,每接到一个活动,就重新写一份,第一次写完。之后就是复制黏贴,再修改,每次活动,测试人员测试也蛮苦恼的。

  虽然复制的是之前的代码,已经经历过一轮测试,但手工操作难免会有这个那个的细节问题,都得重新测试一遍。

  而且定时任务的测试成本还是蛮高的,因为每次测试就要修改时间,来模拟真实环境。测试环境各个组用的都是一套,改了服务器时间有时候还会影响其他组的开发,所以测起来要快而准。

  定时任务(node-schedule)需要三个参数:开始时间、结束时间和循环规则,在测试时这三个参数可能会与线上环境不同,榜单依赖的礼物ID、统计时间在正式和测试也有可能不同。

  所以一开始的时候,测试环境测好后,在发到线上之前还要做一次参数的修改,这其中也有隐患,写错的话不但要修改代码,还要重新合代码,再发布,得走一整套流程。

二、参数配置化

  像定时任务的参数、榜单的参数诸如缓存key、礼物ID、统计时间等,都可配置化。

  得益于之前开发了一套通用配置系统,可将这些参数以JSON格式写到输入库中。

  

  测试环境配置一套,正式环境也配置一套,代码可互不影响。

  并且在更新参数后,不需要再合代码了,只要重新发布一次即可。

  因为定时任务的规则只会在发布时配置一次,后面参数更新后,若不发布,新的参数就不会被执行。

三、定时任务配置化

  虽然参数配置化后,省了合代码,但复制黏贴仍然还要做一次。

  于是在分析运营的需求后,抽象出一套高度可配置化的榜单任务,在后台管理系统中单独开一菜单,将动态的参数全部变得可配置。

  

  得益于之前抽象出了一套通用模板组件,这个页面只花了两个半小时就搭建好了,包括后端接口和列表页面,在列表页面可控制活动的上下线。

  

  数据来源有了之后,就要写定时任务中的逻辑了,其实就是从数据库中读取字段,将字段作为参数传递给榜单方法。

  当然,若有新活动上线,代码还是要重新发布一次的,这一步还没做到自动化。

  未来还有很大的优化空间,像代码发布自动化,榜单前端页面可配置化,目前每次都要重新做一份,其实也可以抽象出来做成可配置化,甚至可以做好页面编辑器,自定义后直接发布。

 

相关文章: