很久很久没写什么东西了，上次用键盘正式的敲文字还是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是不是已经中过奖了，如果中过奖则跳过这次循环并继续抽奖，如果没中奖则入库，表明这层楼的回复中奖了。
此致，从构思到整个完成并自己初步测试一起花了大概三天时间，整整三天啊，我觉得自己效率太低了，中间还为了最长连续子串回顾了一下自己以前写的算法笔记。
上周拿到需求文档
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分钟，测试搞定。
针对这次任务的整个过程，其实没有什么好说的，跟产品人员沟通是很必要的，我只是感叹人跟人之间的交流有太多二义性了，如果第一次我能明确而又大声的表达清楚自己的观点，或者他能从两种不同方案的实现效果出发，整个开发流程可能要不了这么长时间，而对于我来说，以后面对各种需求的时候，要考虑得深一点了，想一想可不可以实现，有哪几种实现方法，各种方法有什么优缺点，怎么抉择，大概花费多少时间，针对这样的需求会引来后面的需求有哪些，最最最重要的是我真的确实了解产品人员的需求么？-想清楚了这些，然后再做回答......切记切记！