小白的经验与教训

题记:说是经验与教训,但这两个其实是一码事。因为往往是吃了教训,才会有经验。

1、认真对待工作中的每一件事

严格遵守研发规范

严格遵守研发规范,每一条都很重要
例:同中心小伙伴,做删除操作时,依赖于其他同事的参数。而用户操作后导致参数为空,而他又没做有效性校验。

导致执行:delete xxx from table where 1=1
结果:还好由业务在测试环境发现,后快速改正才没出生产问题

特别举例:汇报ppt

于我而言,我宁可写花一周写代码,也不愿意用一天时间做ppt。可能这也是大多数程序员同样的心态。很多时候,别人问你做了什么价值贡献,并产生怀疑的时候,你只想拽着他,一起来看看git提交代码行数。

这对同事之间是可以的,但是面对领导呢?你的研发经理会知道你做了什么,产生了哪些价值贡献。但你的领导呢?你要用什么来说服他呢?一起来看你的代码提交量?一起来看你的代码质量吗?答案还是看你的述职PPT。换句话讲,PPT其实是你的价值总结,你都不在乎你的价值总结,那领导更不会在意你的价值了。

优秀的程序员 = 优秀的代码 + 优秀的PPT(当然大可不必做的美观,把想讲的、该讲的讲明白即可)

2、事分轻重缓急

在工作中我们很少可以做到专注于一件事,做完后做下一件。更多是很多事情并发执行。可是我们人是“单线程”的,所以我们一定要学会对事情优先级的排序。下面是我对工作事情做得一个优先级排序。

  1. 生产问题中直接影响主流程无法进行的问题
  2. 阻塞他人工作的事情。例:项目开发中,前端往往是要依赖后端的接口进行开发的,此时后端如果不先给出接口文档则会阻塞前端任务
  3. 需求中主要功能的实现
  4. 已有功能的优化
  5. 其他任务

任务排完,“单线程”就可以快乐的工作了

3、沟通解决99%的问题

工作中的好习惯—勤沟通。

研发跟产品沟通,可以解决需求问题。

研发跟研发沟通,可以解决研发问题。

尤其是大学生,无论研发与产品,刚接手一个系统对其业务知识,需求分析都是不了解的。此时便需要主动沟通,及时询问,将问题解决在沟通阶段。如果把问题拖到了研发阶段,那么你大概率需要用两倍的时间再沟通与再研发。对于研发新人而言,在接到一个新需求时,往往对其无从下手。不知道该怎么做,此时便需要跟组内或认识的研发沟通,吸收他们的经验,理解他们的想法。问题自然迎刃而解。

4、设计先行

设计 > 编码。

架构 = 研发 + 设计。

一个正常的研发,在工作时研发耗时与设计耗时是成反比的。并且同样一个需求,高设计往往比低设计更易扩展,问题更少。

  1. UML图标准建议看这个链接:https://mp.weixin.qq.com/s/EBqtDjx-OZamaJ284VvbSA
  2. 永远记住,没有最完美的设计,只有最符合需求的设计。

5、持续学习,高效赋能

通过学习攻克问题是一件很有成就感的事情。当然,并非你所有的知识都有用武之地。

我们要做的是,防患于未然。同时要注重深度,功能实现要明白原理,原理搞懂,东西用起来更加得心应手

6、向前走半步

研发更加了解产品,甚至可以画原型图。

产品的出身是研发,甚至可以写代码。

7、爱好

80%的人都不喜欢工作,100%的人都有压力。

人的抗压程度是有限度的,就像一个皮球,气打的太满就会炸,这时就需要找到气阀放气。爱好就是这个气阀。通过爱好找到压力的释放口,通过爱好提起对生活的兴趣,甚至通过爱好找到生活的意义。找到属于自己的爱好吧,这很有意义。

最后一句话,送给大家,也送给自己

保持热情,积极面对

热门相关:神秘总裁小小妻   今天也没变成玩偶呢   今天也没变成玩偶呢   异能特工:军火皇后   隐婚试爱:娇妻,好甜!