`
Yinny
  • 浏览: 291908 次
  • 性别: Icon_minigender_2
  • 来自: 杭州
社区版块
存档分类
最新评论

提取各大类目下分享量top500的用户的需求总结

阅读更多
历经了一周几乎天天加班的日子,终于把这个提取靠谱数据的复杂规则需求搞定了,现在对做这次需求做一些总结:
①、接到需求时是三周以前,当时改需求的优先级并不高,所以先忙于其他淘单的优化点,之后的一周里我把提取数据的hive和会调用的接口都已经整理好,但是一直没有开始在云梯上执行,原因是之前志宏说在做每一个需求之前自己把思路理清楚,设计流程跟他讲一遍,避免一些错误和弯路,而他那阶段比较忙,所以拖了几天也没空帮我review一下提取流程,于是我在这几天里也没有做,虽然第二周来我没有等他review就决定自己先去做了,但是因为提取过程比较复杂还是导致后面的时间比较紧张,几乎天天加班,这次我时间安排不合理是影响日常进度的一个重要原因,虽然PM没时间,但是我自己要主动去做这个事情,除了写好hive之外还可以把调用接口判断排除卖家账号,排除黑名单用户,根据评论实拍图排序等代码写好,先测试保证功能正确,之后在跑数据时候不懂的地方再请教一下,这样我就有足够的时间来完成这个需求了,虽然在这过程中可能会出现一些弯路或者错误,但这样才能真正获得成长,这是我总结反思并且日后要改进的第一点;
②、在写代码时候,考虑不全面,走了些弯路,在过滤不合格用户时候只是读取id文件对id进行过滤没有把用户对应的分享数量count同时过滤掉,导致了得到最终用户群体时候,用户id和count无法做匹配了,只能又写方法取读取最早从云梯上获取的表(userId,count),用最终用户id去判断取出count,正确的做法应该是:在第一次读取文件时候就应该把id 和count一起读取进来,对用户进行过滤时候顺便就可以过滤掉对应的count,这样可以避免循环读取文件操作;
③、整个代码里对map的使用过多,不仅耗内存,也被其的生命周期管理搞得很晕,稍不留神就容易出错,昨天听了志宏给我讲解他的设计思路,整个代码里面基本没有用到map,一个一个userId走完所有的流程,比较清晰,而我是单个个批量操作混合在一起,感觉有点乱,因为这个代码基本是一次性使用的,所以后续不想去优化了,嘿嘿;
④、在写代码的时候犯了很多低级错误,这是十分不应该的,浪费了很多时间去检查,以后要改正,写代码时候要集中精力,不要心不在焉,写完之后做一遍大致的检查,把明显的错误排除掉!!
⑤、有时候是想得清楚过程,但是不完全写的出来,这个还是基础不牢,项目经验少,要在平时加强学习和练习并沉淀,赶快成长起来。
分享到:
评论
1 楼 sfdev 2012-04-27  
对第3点,不能放弃优化,这种优化一定要去实战不然成长还只是停留在理论阶段!可以仅仅针对你用map实现的那一段代码进行优化,可以不在项目代码库中优化,但可以单独领出来在自己的本地测试工程里面做优化对比,一个是基于map实现,一个是基于非map实现,实现之后两者做对比,也可以在周分享会上看大家有没有更好的实现方案;
第5点,可以多尝试在纸质笔记本上画画流程图、写写方法级的伪代码和注释,可以很好的帮助理清思路;

相关推荐

Global site tag (gtag.js) - Google Analytics