工作总结
产品层面
- 特效的运用要考虑用户的心理趋向和感受，炫的效果很酷，可能会让人产生某种心理导向。
- 特效的运用要考虑将来功能的扩展，一味的渲染也不一定很好，可能会为后续功能带来难度。
- 一个产品能帮助用户解决至少一个问题，那解决问题会有主流程，引导要强化，比如按钮大，颜色显眼，字体稍大，放置位置移动少。
- 产品不能为照顾运营而偏离主题，或者严重影响美观和主要功能，聚划算妹纸儿们说广告banner曝光度不够，设计变为由轮转变为平铺，但是广告良莠不齐，视觉效果不好，并且主页list仅能显示1、2个商品，影响了主题功能。
代码方面
代码需要审核，程序的代码需要共同学习，完善代码
项目方面
- 计划进度，前紧后慢，提前实施。
- 不拘泥与细节，不干扰整体进度。
- 个人有担当，能者多劳，最大程度保证进度。
- 有问题不能包着，有些项目问题不是一个人的问题，不是一人能担得住的。
- 宝不能压在责任无关人身上，别人的资源、承诺要充分利用，但是最终还是靠自己突破。
- 干一样活的人放在一起，沟通迅速，快速解决问题。
- 早上碰一下，清晰任务；晚上碰一下一下，检查进度。
- bug先把基础性、功能性问题解决，适配、显示、兼容问题靠后。
- 不同网络机型下的跑测，不同网络环境下的测试提前入测。
- 写完一天代码，尽量坚持用findbugs查找潜在危险。
- 同一版本多次发布，或多个版本发布后，记录下的crash问题如果没有版本属性就很难定位,混淆map也对应不上。发板后立即封代码，保证bug日志中的bug发生行数和源码一致。
- 开发新功能、打包、发布过程规范化，规范减少问题发生概率。
- 日志规范：
1). 冗长、惯例日志打到Verbose级别，例如网络返回信息，经常携带大量的信息，会严 重干扰视觉；
2). 细粒度信息打到Debug级别，对出问题时调试有帮助作用，比如某个参数的值，我并 不总想知道是多少，但某些情况我就得看一下；
3). 粗粒度级别信息打到Info级别，比如应用业务主逻辑，运行中重要的过程或关键点；
4). 会出现 潜在错误的信息 或者 可以接受的错误 打到Warn级别，比如某个地方我想警告一下说这里是有问题的，或者可能引出其他什么问题；
5). 错误或者致命信息，理应放到Error级别，血红的颜色很显眼~
管理方面
- 会议总结问题，就一定要着手解决，不解决会议时间就白浪费了。
- 对于人的期望，快速的给予回馈，帮助其向希望的方向发展。