小白的经验与教训
题记：说是经验与教训，但这两个其实是一码事。因为往往是吃了教训，才会有经验。
1、认真对待工作中的每一件事
严格遵守研发规范
严格遵守研发规范，每一条都很重要
例：同中心小伙伴，做删除操作时，依赖于其他同事的参数。而用户操作后导致参数为空，而他又没做有效性校验。
导致执行：delete xxx from table where 1=1
结果：还好由业务在测试环境发现，后快速改正才没出生产问题
特别举例：汇报ppt
于我而言，我宁可写花一周写代码，也不愿意用一天时间做ppt。可能这也是大多数程序员同样的心态。很多时候，别人问你做了什么价值贡献，并产生怀疑的时候，你只想拽着他，一起来看看git提交代码行数。
这对同事之间是可以的，但是面对领导呢？你的研发经理会知道你做了什么，产生了哪些价值贡献。但你的领导呢？你要用什么来说服他呢？一起来看你的代码提交量？一起来看你的代码质量吗？答案还是看你的述职PPT。换句话讲，PPT其实是你的价值总结，你都不在乎你的价值总结，那领导更不会在意你的价值了。
优秀的程序员 = 优秀的代码 + 优秀的PPT（当然大可不必做的美观，把想讲的、该讲的讲明白即可）
2、事分轻重缓急
在工作中我们很少可以做到专注于一件事，做完后做下一件。更多是很多事情并发执行。可是我们人是“单线程”的，所以我们一定要学会对事情优先级的排序。下面是我对工作事情做得一个优先级排序。
- 生产问题中直接影响主流程无法进行的问题
- 阻塞他人工作的事情。例：项目开发中，前端往往是要依赖后端的接口进行开发的，此时后端如果不先给出接口文档则会阻塞前端任务
- 需求中主要功能的实现
- 已有功能的优化
- 其他任务
任务排完，“单线程”就可以快乐的工作了
3、沟通解决99%的问题
工作中的好习惯—勤沟通。
研发跟产品沟通，可以解决需求问题。
研发跟研发沟通，可以解决研发问题。
尤其是大学生，无论研发与产品，刚接手一个系统对其业务知识，需求分析都是不了解的。此时便需要主动沟通，及时询问，将问题解决在沟通阶段。如果把问题拖到了研发阶段，那么你大概率需要用两倍的时间再沟通与再研发。对于研发新人而言，在接到一个新需求时，往往对其无从下手。不知道该怎么做，此时便需要跟组内或认识的研发沟通，吸收他们的经验，理解他们的想法。问题自然迎刃而解。
4、设计先行
设计 > 编码。
架构 = 研发 + 设计。
一个正常的研发，在工作时研发耗时与设计耗时是成反比的。并且同样一个需求，高设计往往比低设计更易扩展，问题更少。
- UML图标准建议看这个链接：https://mp.weixin.qq.com/s/EBqtDjx-OZamaJ284VvbSA
- 永远记住，没有最完美的设计，只有最符合需求的设计。
5、持续学习，高效赋能
通过学习攻克问题是一件很有成就感的事情。当然，并非你所有的知识都有用武之地。
我们要做的是，防患于未然。同时要注重深度，功能实现要明白原理，原理搞懂，东西用起来更加得心应手
6、向前走半步
研发更加了解产品，甚至可以画原型图。
产品的出身是研发，甚至可以写代码。
7、爱好
80%的人都不喜欢工作，100%的人都有压力。
人的抗压程度是有限度的，就像一个皮球，气打的太满就会炸，这时就需要找到气阀放气。爱好就是这个气阀。通过爱好找到压力的释放口，通过爱好提起对生活的兴趣，甚至通过爱好找到生活的意义。找到属于自己的爱好吧，这很有意义。
最后一句话，送给大家，也送给自己
保持热情，积极面对