对一种竞猜活动设计的一些思考

这个时间段最火的体育活动是什么，当然是世界杯。随着世界杯的还有各家公司在产品中增加的世界杯竞猜活动，我所在的公司也增加了该活动（吐槽下运营在有人提前提醒的情况下结果还是等到世界杯进行了快一半了才提出要做），其中部分功能由我进行开发，但是在开发过程中由于经验不足出现了一系列的问题，给同事带来了不小的麻烦，很是羞愧。不过最终活动还是成功上线了，在这里写下对这次竞猜活动开发的一些总结。

---

• 内容
  根据运营和产品提出的需求，这次活动的内容是让用户猜每场比赛的总进球数，用户每场比赛有一次免费的机会，每天分享获得一次机会，每天在 APP 中消费一次获得一次机会。主页上展示的是两个比赛日的比赛列表以及用户剩余的不免费的次数。

---

• 关键思考过程
  一开始我的思路是将比赛日定义为每天中午的12点到明天中午的12点，在数据库中找比赛时间在这个区间内的比赛。同时有一张用户竞猜记录表来记录用户的竞猜的场次和竞猜的大小。判断剩余次数的时候先取当天的比赛，然后循环在竞猜记录表中查询用户对该场次的竞猜次数，如果不为零的话就在减去竞猜次数再减去一（减一是因为主页展示的剩余次数不包括免费次数）。

---

• 遇到的问题
  1、首先是时间上的问题。
  由于做这个需求的时候的不细心，没看清产品的具体需求，产品需求是展示两个比赛日的比赛，结果写代码的时候写成一个比赛日的比赛，导致后续一系列问题。同时由于比赛日并不是我们日常中使用的北京时间，导致在时间的换算上很麻烦。在时间的换算上使用了 Calendar 类，计算的时候先取当天零点，然后进行一系列的计算。一开始没有根据时间段0-12，12-24来进行区分计算，这样在一过0点的时候日期就会加一天，由昨天中午12点-明天中午12点比赛变成今天中午12点到后天中午12点，本来该继续显示的比赛就消失了。在后发现问题了就根据时间段来区分计算时间，解决了问题。
  2、竞猜剩余次数的问题。
  采用原来设想中的方法计算剩余次数的话会导致已经结束的比赛的竞猜次数也从总的机会中减去，用户的剩余竞猜次数会随着时间的改变减少。而且这个问题是在上生产环境后发现的，比较严重。跟同事讨论后原本想临时修改代码的设计方案，但是我在评估后发现采用新的设计方案重新写代码，可能会引入新的无法预估的BUG，增加测试同学的工作量，而且那时候是在周末，同学们都是在家里远程支持。就决定还是在原有设计方案的基础上进行小范围的修改来修复 BUG。最终修复方式为在插入竞猜记录时也记录下该竞猜记消耗的是免费的次数还是付费的次数，最后在统计剩余付费次数的时候只要统计当天获得的付费次数，再减去今天已竞猜的付费次数，就得到今天剩余的付费竞猜次数。在修复这个 BUG 的时候占用了同事们周末的休息时间，真的是很不好意思。

---

• 在最后的思考
  有同事指出设计方案在一开始就存在问题，不应该通过几张表去查询然后计算出剩余次数。类似的竞猜活动应该在用户获得竞猜机会后往一张竞猜机会表里插入一条记录 机会来源、机会有效期、机会是否消耗 的记录。然后用户在竞猜的时候查询是否有竞猜机会，然后修改竞猜机会的状态再进行竞猜操作。
  确实这种设计方案相比较我的原始设计方案而言较简单较方便，但是采用这个方案就意味着要在用户消费的那部分代码里加上一部分代码来插入机会表。而我一开始考虑原始设计方案就是想要避免在那部分历史代码中加入更多的代码，在活动结束后直接删除接口和 Manager 类即可完全删除无用代码。原始的设计方案确实不可取，但是私以为修改后的最终版本还是可以有一较之力。

---

• 一些总结
  从上述开发过程中我也算是收获了一些经验：
  1、涉及到不标准的当地时间的时间段的，一定要仔细仔细再仔细，不然很容易弄混。
  2、时间类的使用：Java 内部的部分老的时间类存在线程安全方面的问题，这个问题我在解决了 bug 后也去看了一下，后面也会写一下总结。
  3、类似的竞猜活动一定要将竞猜时消耗的是什么类型的机会记录清楚，不管是单独一张机会表或者在竞猜记录中的一个字段去记录，除非只有单一的一种类型的机会，那可以不去记录。
  4、在开发中经验还是相当重要的，其实目前大部分功能都有比较成熟的设计解决方案，不熟悉的功能、领域在开发前最好在网上搜索一下或者向有经验的同学学习一下该怎样设计，能很大程度上减少在开发过程中的犯错。