搞不定抽奖系统的技术不是一个好程序员(5)

  11月5日,抽奖系统开发的第五天,终于是周一了。

催进度

  产品、运营都来上班了,第一件事就是过来问技术,抽奖系统做的怎么样了?在产品、运营的心里,都开发了4天了,估计都能出一个测试版本了。

  技术打开了开发工具,秀了一遍代码,当然,这个过程直接被跳过了。然后启动了Go抽奖系统,还是可以展示一下后台管理功能的。产品、运营看过之后,觉得很乐观嘛,这么丰富的管理功能考虑倒是很齐全呀,但是更加关注抽奖的功能。但是,技术也只是完成到后台管理功能,计划中和实际上,也是今天开始抽奖接口。技术这么一通演示和解释,产品、运营也大概明白进度了,看来跟最开始预期的也还算相符,也就没有更多催促。

  送走了产品和运营,技术终于可以开始构建抽奖系统前台相关的功能接口啦。

通用功能实现

  首先是把用户的登录、退出功能实现了。由于要用到公司统一的用户中心,所以用户登录、退出这块,只需要实现了公司统一的用户中心的用户验证就可以啦。登录的页面直接去用户中心,完成后跳转过来,然后识别出来登录用户的cookie数据,就可以确认用户的登录状态了。这块的功能,还是很熟练了,毕竟之前也是做过好几个系统,都用到用户中心,只是开发语言不同而已。

抽奖接口构思

  接着就要开始抽奖接口了。先定义了抽奖接口 /lucky ,把里面的处理流程,先用注释的方式写了一下 1,2,3,4…10,后面具体的实现,就是把这些注释点补充完成就好了。定义好了处理逻辑,回头看好像很容易,就是写一些注释而已,但是在提前总结的过程还是很困难的,要不断推演一个真正的抽奖系统,会做哪些事情,会有哪些步骤。然后不断的调整才有了最后的这个注释的逻辑过程。把整个抽奖的逻辑流程定义下来,后面的开发就还算容易,只是具体的开发工作量了。

  抽奖用户验证,这个功能在用户登录、退出的时候,已经有实现相应的公共方法,所以用起来就可以了。

抽奖限制规则

  用户抽奖次数的限制,就需要用到前面实现的数据处理封装类了,要去查数据库,也要更新数据库。先查询出来,今天这个用户参与的次数,是否超过了限制。没有超过限制,还需要给今天参与次数+1。

  IP限制规则比用户稍微复杂了一些,有一个是限制中大奖,有一个是直接不能参与,但是逻辑也是类似。先查询IP的今天参与次数,后面再更新这个次数+1。

  前面的规则都通过之后,就要把奖品都查询出来,过滤掉无效的奖品(过期了?没开始?没有奖品等)。有奖品才可以继续抽奖,所以这也就是一个抽奖前的准备工作,也是必不可少。

  写完代码,还运行不了,没多少功能可以实际运行的,但是完成这些代码逻辑,也是一整天过去了。产品、运营也不知道是6点回去的,还是7点,反正是早就不见人影了。而技术,只能是自己去赶最后一班地铁了。虽然一天很累了,但是总算也是没有卡住,没有拖累进度,反倒是有很多的成就感呢!

老师总结

  技术、产品、运营很多时候是又统一又矛盾,他们也都关心抽奖系统,但是实现的环节又爱莫能助。恰恰是前期实现的环节,压力是很大的,所以这时候技术的难处就显得更加明显。不论是一个人在思考、在实现,还是一个人在加班、在熬夜,长期以往,产品、运营和技术的分歧也就会更加恶化。这是一个很严重的问题,没有好的产品、运营,技术就会做得更加辛苦。

  这里,技术在实现的过程中,有一个很好的工作方法,就是在实现之前,通过注释的方式,把整个逻辑和过程都梳理和记录下来,把整体的逻辑框架定一下来,之后再来具体的细节实现,这样就可以条理清晰,整体和局部都可以兼顾,避免走弯路,更少的犯错。

一起来学习《Go抽奖系统》,也许能帮你少走弯路。

上一篇《搞不定抽奖系统的技术不是一个好程序员(4)

下一篇《搞不定抽奖系统的技术不是一个好程序员(6)

点赞