本周需要对交易主题的重保日期进行指标预热,指标预热是我进公司做的第一个项目,很幸运能从用户的角度审视自己的产品,其中该平台提供了请求管理界面(通过请求的调用来对指标进行预热)、任务管理界面(配置依赖的请求信息以及请求的拆分规则,进而将请求裂变为多个)。
当前交易主题的需要预热11个任务,每个任务有10~50个不等的请求,需要为每个请求添加16个特定且固定的日期。比较困扰用户的是当前指标预热不能够为任务里的请求里的自定义日期函数批量的增添修改时间。
如果我通过页面上徒手增添的方式,假定每次选择日期添加检查保存需要20秒,需要花费11*30*16次*20/60/60=29个小时。因此我就开始考虑能不能通过对指标预热增加批量修改的功能进行完成该工作,该接口入参应包含批量选择的任务ID、请求ID、函数ID以及修改内容,如果需要真实产品化应该还需要前端同学支持开发。但其实还存在一个更加简便的方法。
因为在修改预热任务时,是先get获取该任务的全部信息(含任务任务ID、各个请求ID、各个函数ID以及各自内容),用户在页面修改后点击“提交”即将任务的全部信息update进数据库。因此我拿到任务编辑提交时的传参(即任务的全部信息),对其中自定义日期函数中的时间进行全文的查找替换,并用deep test调取更新接口完成自定义日期函数批量的增添修改时间。连同思考测试验证检查大概一共耗时30分种,效率提升98.28%(原计划时间-实际完成时间之差比上原计划时间)。
有几点思考:
1、贴近用户才能更好的完善产品。
指标预热虽能够提供各种请求批量生成的规则简化用户配置,但用户每年对大促重保日期的批量修改能力仍有强烈诉求。真正从用户实际使用场景出发才能发现产品能力提升的突破点在哪里。
2、编程思维的灵活运用。
开发人员在使用一些产品时,对于发现的一些操作或使用上的繁琐项,应当要时时要有简化繁琐为己任的意识与主动性,要树立任何繁琐重复复杂的工作都能够被合理简化的决心与意识。繁琐与重复的工作是在高估人性,势必会因为人的失误与素质的参差带来系统性风险。
5万+

被折叠的 条评论
为什么被折叠?



