工作总结

产品层面

  1. 特效的运用要考虑用户的心理趋向和感受,炫的效果很酷,可能会让人产生某种心理导向。
  2. 特效的运用要考虑将来功能的扩展,一味的渲染也不一定很好,可能会为后续功能带来难度。
  3. 一个产品能帮助用户解决至少一个问题,那解决问题会有主流程,引导要强化,比如按钮大,颜色显眼,字体稍大,放置位置移动少。
  4. 产品不能为照顾运营而偏离主题,或者严重影响美观和主要功能,聚划算妹纸儿们说广告banner曝光度不够,设计变为由轮转变为平铺,但是广告良莠不齐,视觉效果不好,并且主页list仅能显示1、2个商品,影响了主题功能。

代码方面

代码需要审核,程序的代码需要共同学习,完善代码

项目方面

  1. 计划进度,前紧后慢,提前实施。
  2. 不拘泥与细节,不干扰整体进度。
  3. 个人有担当,能者多劳,最大程度保证进度。
  4. 有问题不能包着,有些项目问题不是一个人的问题,不是一人能担得住的。
  5. 宝不能压在责任无关人身上,别人的资源、承诺要充分利用,但是最终还是靠自己突破。
  6. 干一样活的人放在一起,沟通迅速,快速解决问题。
  7. 早上碰一下,清晰任务;晚上碰一下一下,检查进度。
  8. bug先把基础性、功能性问题解决,适配、显示、兼容问题靠后。
  9. 不同网络机型下的跑测,不同网络环境下的测试提前入测。
  10. 写完一天代码,尽量坚持用findbugs查找潜在危险。
  11. 同一版本多次发布,或多个版本发布后,记录下的crash问题如果没有版本属性就很难定位,混淆map也对应不上。发板后立即封代码,保证bug日志中的bug发生行数和源码一致。
  12. 开发新功能、打包、发布过程规范化,规范减少问题发生概率。
  13. 日志规范:
    1). 冗长、惯例日志打到Verbose级别,例如网络返回信息,经常携带大量的信息,会严                                    重干扰视觉;
    2). 细粒度信息打到Debug级别,对出问题时调试有帮助作用,比如某个参数的值,我并    不总想知道是多少,但某些情况我就得看一下;
    3). 粗粒度级别信息打到Info级别,比如应用业务主逻辑,运行中重要的过程或关键点;
    4). 会出现 潜在错误的信息 或者 可以接受的错误 打到Warn级别,比如某个地方我想警告一下说这里是有问题的,或者可能引出其他什么问题;
    5). 错误或者致命信息,理应放到Error级别,血红的颜色很显眼~
    

管理方面

  1. 会议总结问题,就一定要着手解决,不解决会议时间就白浪费了。
  2. 对于人的期望,快速的给予回馈,帮助其向希望的方向发展。
分享到 评论