一方面为了总结和提醒自己，另一方面也分享给后来者少走些弯路。
制定方案：
- 如实现下载和设计定时任务时，经常没有考虑到失败的情况下怎么办。比如重试、失败时告知谁谁谁，以及要不要保存错误信息，保存什么程度的错误信息。
- 接口的同步异步：除了下载大文件、上传这种必须要同步接口外，其实很多其他耗时较长的接口(>3s),都应该考虑做成异步的。
- 实时性：是否要实时计算，性能能否满足实时计算
- 存储的地方：比如既可以存mysql又可以存hive表的话，要选哪个。既可以离线计算，又可以实时计算存到mysql的话要选哪个。
- 开发一个SDK或者一个jar包，不应该引用大而全的包，否则会让使用这个包的项目产生包污染
沟通汇报：
- 向同事请教时，最好不要只提出问题，而不给出解决方案或者思考，最好让领导做选择题。
- 卡在一个地方太长时（1h+），及时反馈。如果任务很紧急，这个时间可以缩短到10min甚至更短。
- 测试环境部署完，或者重要数据产生后，就让业务体验，避免上线以后发现需求提的不对又返工
- 上线完，要让业务体验
- 如果老板让调研能不能先把XXX需求上线了，别把这事开完会就不管了，要跟进至少T+1给回复
- 找老板review方案时，如果是其中某一个细节，虽然不是方案的主要点，但既然让老板review这个点，就要把这个点搞明白，提出自己的方案，让老板做选择题，而不是让老板给出方案，因为他了解的可能还不如我多，但他的经验很丰富。
排期（预估工作时长）：
- 把写技术方案的时间留出来
- 把处理上一个需求的测试问题的时间空出来：demo show+测试用例评审+测试同学过来问问题+处理bug+处理业务同学提的tapd里没有的点+部署和测试预发布+部署和测试线上的时间
- 把MR的时间、自己测试的时间留出来。
- 如果觉得以上时间不好完全计算，那么可以把你预估的时长乘以一个系数，比如你预估3天，那么31.2=3.6，31.3=3.9，也就是开发3天，留1天缓冲。
- 像离线数据表(hive)这类数据量大的表，如果要修改逻辑、增加字段，要把对数、校验数据、前后diff对比的时间考虑上，而且对数的时间比开发的时间要多。
- 一个是做事情的效率，一个是做事情的方式，不要总等着别人问
- 当你手头的需求还没做完时，有人问你要下一个需求的排期，先给工作量，如果要具体到某日的话，那把前一个需求的结束日期多留一些buffer，必须留个一天半天的，因为每个人都要运维线上问题，都有会议要开。
沟通：
- 明确目的是什么
- 跑偏时，及时回正
- 和高级别沟通前，想好要说的话
- 惹不起的人，对他客气点
- 领导交代事情，没理解的话，要再确认下，哪怕被人烦，也好过理解错了做出一个错的东西出来好
如果线上有问题：
- 先上升，周知身边人
- 别着急尽快恢复，因为这时候脑子乱，很容易出错
- 最好先写好恢复数据的脚本，提前测试好，这样能保护自己
- 修改mysql的语句，要发别人review。甚至做的更厉害一些，写sql的执行sql的要是2个人
- 线上操作是要特别小心的
- 如有遇到问题，及时同步进展：正在做什么，计划要做什么
提升：
- 自己对事情有个规划，而不是被别人push着再去做。
- 有一些事情可以做60分、80分、100分，可以逐步的把事情做得更好，当然也要平衡时间成本。
- 积累和分享：把平常的事情作总结，积累下来
- 提高效率大法：基础知识+经验+动态的一次一事+ddl大法
- 问问题前先做好准备，带着准备去问，别人家简单一问，我就被驳倒了。
- 做需求和做事情的区别。
