去年年底，公司为进一步响应全民健身国家号召，践行绿色低碳生活方式，根据年度重点工作安排，准备开展“绿色出行 你我同行”千人健步走PK赛活动，活动为期四周，三周后开始。之前都是使用的市场上的云产品，不进收费高，还不能做定制化业务，今年刚成立自研小组，这个任务自然而然就落在了我们头上了。
之前没有接触过此类需求，并且开发+测试时间只有三周时间，对我们的考验还是蛮大的，产品经理和开发同时开工，借鉴前年使用的云上产品的大赛展示元素和页面布局，同时将今年特有的规则进行合并，做为项目经理我首先做了以下几个方面的工作：
1）产品经理首先借鉴之前的大赛做原型设计，同时结合今年的规则做布局上的调整
2）前后端开发人员查看腾讯小程的api开发文档，了解到微信运动的对接方案，因为健步走说白了就是读取的微信运动的步数，所以只有了解对应api的规则，你才能做出合适的功能，事实证明这些决策都是正确的。
3）后端的开发人员根据业务规则进行数据表结构的设计，基于业务数据的表设计对于代码的开发会有很大的帮助
以上三步工作进行的同时，我们同业务人员沟通，提前获取到本次大赛的参赛人员名单，因为是公司内部的活动，所以只允许公司内部人员进行报名参加。
经过近一周的时间，准备工作已经完成 ：
1）基本确定了参赛人员数量（2000-3000人）
2）参赛规则分为个人排名，部门排名，小组排名 。公司有近100个部门，分成了20个小组，其中针对50岁以上人员专门组成了一个小组，该小组的里面的人员单独排名，和其他19个小组的人员排名相互独立，也是为了考虑年纪大的同事不适宜走太远的路而考虑。
3）小程序读取微信运动首先需要小程序认证，要求小程序的主体必须为公司所有，公司提供营业执照等相关证件缴纳一定的费用(300块)即可完成认证。
4）微信运动的读取必须是人为主动发起，不允许自动执行，这个规则直接就否定了之前我们定期去采集微信运动数据的想法，所以开工之前，一些技术上的点还是要提前确认，否则后期改造起来就耗时费力。
接下来的工作就相对简单了，由产品经理进行需求宣讲，原型讲解，开发人员根据原型进行表结构的调整，就剩下一个唯一的难点了：如何做到排名的刷新？公司参赛人员有2500人左右，每个人随时都有可能打开小程序查看排名，如何保证每个人看到的名字是实时的，这个问题也也确实花了一定的时间来验证，但是想了三种方案:
1、每个人打开的同时，都进行一次排名的计算，但是因为既要计算 个人在总公司的排名，个人在部门的排名，个人在小组的排名，还要计算部门间的排名，小组间的排名；这么大的工作量第一比较耗时，第二对服务器的压力也比较大，所以pass了此种方案
2、放入缓存，将每个人最近一次的数据放入缓存，这样计算的速度就会加快很多，但是此种方案依然需要计算多种排名，并且缓存数据的计算我们技术并不成熟，可能需要花费一定的时间，所以该方案也pass掉了
3、第三种方案，也就是当时的最后一种方案，该方案放弃了实时排名的逻辑，因为排名其实是一个整体的数据，无论任何一个人进来看到的排名理论上应该是一样的(只是理论上，毕竟上次进来和本次进来可能上传的步数有差异，个人排名会发生变化)，所以我们在实时性上做了一定的妥协，每5分钟更新一次排名， 并且我们会把最近更新的时间醒目的展示在页面顶部，方便员工查看。
说干就干，确定了方案，如何实现定时计算排名的逻辑，因为排名的计算相对比较负责，如果用java代码开发定时逻辑的话，里面的计算逻辑和sql将会十分复杂，后期运维也比较困难。当时我们用的是oracle数据库，之前在联通做过数据分析相关的工作，对存储过程比较熟悉，所以就采用存储过程的方式来进行计算排名，通过job定时调用存储过程，存储过程将排名计算完毕后，放入对应的结果表中，对前端开放的接口只需要从结果表中读取数据即可，既简化了前后端交互，又将数据的计算剥离出来，方便后期的问题定位。
这个小程序我们开发了有10天左右，各种测试、部署完毕后，正好符合业务人员的时间要求，在真正的使用过程中还有一些排名小问题，因为是存储过程开发，所以调整存储后直接就进行了解决，前后端代码无需改动。
腾讯的api文档不得不说真的非常详尽，遇到的问题一般都能够在里面找到答案，提供的在线接口测试非常贴心使用，极大提高了开发人员的效率。
声明：本网页内容旨在传播知识，若有侵权等问题请及时与本网联系，我们将在第一时间删除处理。E-MAIL:dandanxi6@qq.com
