提取各大类目下分享量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点，可以多尝试在纸质笔记本上画画流程图、写写方法级的伪代码和注释，可以很好的帮助理清思路；