很久很久没写什么东西了,上次用键盘正式的敲文字还是09年。直接导致表达能力下降,现在跟人沟通比人老是听不懂(应该是我没有说到重点吧),所以从今天开始慢慢养成写博客的习惯,读后感也行,技术总结也行,写着自己看,聊以自慰。
今天终于开始测试盖楼抽奖程序了,现在写下点总结
上周拿到需求文档
1. 形式: 以抢楼形式为主,但是不抢时间,不抢楼层,而是抢小姨子卡。事先请技术设定小姨子卡的出现几率为5%左右,然后将成都车展美女图库导入,网友跟帖抢楼,凡是出现小姨子的楼层,则该楼层网友获奖。同时可请技术制作一个大奖程序,将帖子UID与程序绑定,在500分之1的概率内出现一张特别设定的图片,若出现此图片,则获奖大奖,每帖限出现1次,同时设定: 每位网友限制获奖一次, 超过时间节点后跟帖无效。
从今天的结果来看,上面的红色部分就是我忽略或者没有弄懂的地方,其中 以抢楼形式为主,但是不抢时间,不抢楼层 我还是没有完全弄懂,好像就是强调中奖的那条回复跟楼层和时间没有关系。
脑中的第一感觉,就是在特定的帖子中,每次有人回复就可能(两种不同的概率)会出现中奖图片,不是很复杂的样子。
第一天跟需求沟通后,告知要每20楼出现一个小奖。每500楼出现一次大奖,加上及时刷新的效果。突然我觉得有点复杂,思考了半天,跟技术同事商量后,开始自己新建两个表了(不然会影响速度,现存的表中数据量都很大)。
第二天需求人员开始休假了(5天),接下来的1天我完成盖楼抽奖的思路是:
1.首先通过循环获取这个帖子的回复数N(20 || 500),如果能取到N条 就开始第二步,不能的话就跳出(数据库语句limit..)
2.取出的N条后,判断最大连续子串的长度Len,如果Len>10(说明有连续的10条回复是同一个uid发出的),则unset这Len条数据,然后从数据库中再往后取Len条数据(注意循环的控制),然后合并这些数据array_merge(其实还是N条)得到$posts,然后进行第三步
3.再一次while循环,从$posts中随机取出一个pid(rand(0,N-1)),然后查看这条post的uid是不是已经中过奖了,如果中过奖则跳过这次循环并继续抽奖,如果没中奖则入库,表明这层楼的回复中奖了。
此致,从构思到整个完成并自己初步测试一起花了大概三天时间,整整三天啊,我觉得自己效率太低了,中间还为了最长连续子串回顾了一下自己以前写的算法笔记。
--当然故事的结局总是好了,今天早上提需求的那哥们儿回了,在测试之前我跟他大概说了一下,当然我呆呆的只负责给他一条条讲他当初要求的基本功能。后面他思索了一会儿,否定了20楼一定出一次奖的要求,改成每次发帖都有1/20的概率出现奖品,这下彻底跟楼层没有关系了,跟我第一感觉的效果一样,也跟我们第一次讨论时我的观点一次,也不用测试了,相当于重写,因为时间比较紧,明天下午他就要出发去车展现场了,我回来改了20分钟,测试搞定。
针对这次任务的整个过程,其实没有什么好说的,跟产品人员沟通是很必要的,我只是感叹人跟人之间的交流有太多二义性了,如果第一次我能明确而又大声的表达清楚自己的观点,或者他能从两种不同方案的实现效果出发,整个开发流程可能要不了这么长时间,而对于我来说,以后面对各种需求的时候,要考虑得深一点了,想一想可不可以实现,有哪几种实现方法,各种方法有什么优缺点,怎么抉择,大概花费多少时间,针对这样的需求会引来后面的需求有哪些,最最最重要的是我真的确实了解产品人员的需求么?-想清楚了这些,然后再做回答......切记切记!
上周拿到需求文档
1. 形式: 以抢楼形式为主,但是不抢时间,不抢楼层,而是抢小姨子卡。事先请技术设定小姨子卡的出现几率为5%左右,然后将成都车展美女图库导入,网友跟帖抢楼,凡是出现小姨子的楼层,则该楼层网友获奖。同时可请技术制作一个大奖程序,将帖子UID与程序绑定,在500分之1的概率内出现一张特别设定的图片,若出现此图片,则获奖大奖,每帖限出现1次,同时设定: 每位网友限制获奖一次, 超过时间节点后跟帖无效。
从今天的结果来看,上面的红色部分就是我忽略或者没有弄懂的地方,其中 以抢楼形式为主,但是不抢时间,不抢楼层 我还是没有完全弄懂,好像就是强调中奖的那条回复跟楼层和时间没有关系。
脑中的第一感觉,就是在特定的帖子中,每次有人回复就可能(两种不同的概率)会出现中奖图片,不是很复杂的样子。
第一天跟需求沟通后,告知要每20楼出现一个小奖。每500楼出现一次大奖,加上及时刷新的效果。突然我觉得有点复杂,思考了半天,跟技术同事商量后,开始自己新建两个表了(不然会影响速度,现存的表中数据量都很大)。
第二天需求人员开始休假了(5天),接下来的1天我完成盖楼抽奖的思路是:
1.首先通过循环获取这个帖子的回复数N(20 || 500),如果能取到N条 就开始第二步,不能的话就跳出(数据库语句limit..)
2.取出的N条后,判断最大连续子串的长度Len,如果Len>10(说明有连续的10条回复是同一个uid发出的),则unset这Len条数据,然后从数据库中再往后取Len条数据(注意循环的控制),然后合并这些数据array_merge(其实还是N条)得到$posts,然后进行第三步
3.再一次while循环,从$posts中随机取出一个pid(rand(0,N-1)),然后查看这条post的uid是不是已经中过奖了,如果中过奖则跳过这次循环并继续抽奖,如果没中奖则入库,表明这层楼的回复中奖了。
此致,从构思到整个完成并自己初步测试一起花了大概三天时间,整整三天啊,我觉得自己效率太低了,中间还为了最长连续子串回顾了一下自己以前写的算法笔记。
--当然故事的结局总是好了,今天早上提需求的那哥们儿回了,在测试之前我跟他大概说了一下,当然我呆呆的只负责给他一条条讲他当初要求的基本功能。后面他思索了一会儿,否定了20楼一定出一次奖的要求,改成每次发帖都有1/20的概率出现奖品,这下彻底跟楼层没有关系了,跟我第一感觉的效果一样,也跟我们第一次讨论时我的观点一次,也不用测试了,相当于重写,因为时间比较紧,明天下午他就要出发去车展现场了,我回来改了20分钟,测试搞定。
针对这次任务的整个过程,其实没有什么好说的,跟产品人员沟通是很必要的,我只是感叹人跟人之间的交流有太多二义性了,如果第一次我能明确而又大声的表达清楚自己的观点,或者他能从两种不同方案的实现效果出发,整个开发流程可能要不了这么长时间,而对于我来说,以后面对各种需求的时候,要考虑得深一点了,想一想可不可以实现,有哪几种实现方法,各种方法有什么优缺点,怎么抉择,大概花费多少时间,针对这样的需求会引来后面的需求有哪些,最最最重要的是我真的确实了解产品人员的需求么?-想清楚了这些,然后再做回答......切记切记!