11月5日，抽奖系统开发的第五天，终于是周一了。
催进度
产品、运营都来上班了，第一件事就是过来问技术，抽奖系统做的怎么样了？在产品、运营的心里，都开发了4天了，估计都能出一个测试版本了。
技术打开了开发工具，秀了一遍代码，当然，这个过程直接被跳过了。然后启动了Go抽奖系统，还是可以展示一下后台管理功能的。产品、运营看过之后，觉得很乐观嘛，这么丰富的管理功能考虑倒是很齐全呀，但是更加关注抽奖的功能。但是，技术也只是完成到后台管理功能，计划中和实际上，也是今天开始抽奖接口。技术这么一通演示和解释，产品、运营也大概明白进度了，看来跟最开始预期的也还算相符，也就没有更多催促。
送走了产品和运营，技术终于可以开始构建抽奖系统前台相关的功能接口啦。
通用功能实现
首先是把用户的登录、退出功能实现了。由于要用到公司统一的用户中心，所以用户登录、退出这块，只需要实现了公司统一的用户中心的用户验证就可以啦。登录的页面直接去用户中心，完成后跳转过来，然后识别出来登录用户的cookie数据，就可以确认用户的登录状态了。这块的功能，还是很熟练了，毕竟之前也是做过好几个系统，都用到用户中心，只是开发语言不同而已。
抽奖接口构思
接着就要开始抽奖接口了。先定义了抽奖接口 /lucky ，把里面的处理流程，先用注释的方式写了一下 1,2,3,4…10，后面具体的实现，就是把这些注释点补充完成就好了。定义好了处理逻辑，回头看好像很容易，就是写一些注释而已，但是在提前总结的过程还是很困难的，要不断推演一个真正的抽奖系统，会做哪些事情，会有哪些步骤。然后不断的调整才有了最后的这个注释的逻辑过程。把整个抽奖的逻辑流程定义下来，后面的开发就还算容易，只是具体的开发工作量了。
抽奖用户验证，这个功能在用户登录、退出的时候，已经有实现相应的公共方法，所以用起来就可以了。
抽奖限制规则
用户抽奖次数的限制，就需要用到前面实现的数据处理封装类了，要去查数据库，也要更新数据库。先查询出来，今天这个用户参与的次数，是否超过了限制。没有超过限制，还需要给今天参与次数+1。
IP限制规则比用户稍微复杂了一些，有一个是限制中大奖，有一个是直接不能参与，但是逻辑也是类似。先查询IP的今天参与次数，后面再更新这个次数+1。
前面的规则都通过之后，就要把奖品都查询出来，过滤掉无效的奖品（过期了？没开始？没有奖品等）。有奖品才可以继续抽奖，所以这也就是一个抽奖前的准备工作，也是必不可少。
写完代码，还运行不了，没多少功能可以实际运行的，但是完成这些代码逻辑，也是一整天过去了。产品、运营也不知道是6点回去的，还是7点，反正是早就不见人影了。而技术，只能是自己去赶最后一班地铁了。虽然一天很累了，但是总算也是没有卡住，没有拖累进度，反倒是有很多的成就感呢！
老师总结
技术、产品、运营很多时候是又统一又矛盾，他们也都关心抽奖系统，但是实现的环节又爱莫能助。恰恰是前期实现的环节，压力是很大的，所以这时候技术的难处就显得更加明显。不论是一个人在思考、在实现，还是一个人在加班、在熬夜，长期以往，产品、运营和技术的分歧也就会更加恶化。这是一个很严重的问题，没有好的产品、运营，技术就会做得更加辛苦。
这里，技术在实现的过程中，有一个很好的工作方法，就是在实现之前，通过注释的方式，把整个逻辑和过程都梳理和记录下来，把整体的逻辑框架定一下来，之后再来具体的细节实现，这样就可以条理清晰，整体和局部都可以兼顾，避免走弯路，更少的犯错。
一起来学习《Go抽奖系统》，也许能帮你少走弯路。
