前言
中秋国庆双节至,旅行or回乡探亲基本是大家的选择,看看风景或陪陪家人确实是个难得的机会。不过我的这次假期选择了闭关,不探亲,不会友,利用这个假期重新调整总结一下,为2023最后的三个月再奋斗一把。
今天跟大家分享几个工作中的好习惯或者说是心态,虽然道理简单,但却很容易被忽略。
case1 不想当然
在工作中是不是经常会遇到这种情况:看着自己改的一段代码,想当然的以为改动量不大,自己在开发中考虑的已经非常充分了,认为没必要再去测试或全部测试,代码也不必找同事review,但往往问题就容易在这些地方出问题,而且出的问题恰恰就是被忽略了。
思考:工作中,我们可能会犯一些错误,但千万不要范这种误以为的错误,这种错误特别低级,深究起来也很难解释。
由于人天生的惰性,不愿意多付出多余的精力去干自以为没意义的事情,所以就需要我们不想当然,改了代码就要充分测试,复杂逻辑变动需要约同事去review。
case2 不为了解决问题而解决问题
在开发中,遇到Bug大家是不是有过这种先把问题解决了再说,导致解决了一个Bug又冒出一个新的Bug。比如一个DTC在上电1min中左右会报出来,但上电3min之后就正常了,这时候大家是直接给这个DTC加一个3min的延时诊断,还是说去探究下1min左右会报出来的根本原因,再根据根本原因去解决?
单就上述的case,很多同学肯定会选把根本原因查出来,但实际开发中由于节奏快,任务重,真正遇到的时候可能就不一定会选哪个了,针对这些类似问题我个人的工作习惯是:
情况1:对于时间紧的问题,且验证充分可临时解决的问题,先把问题初步隐藏掉,但初步交付后还是需要尽力去查找问题的根本原因,争取在下一次软件迭代周期将根本问题解决掉;
情况2:对于不太紧急的问题,一定需要查出根本原因,知其然也知其所以然。
case3 不留问题死角
不知道大家也没有听过“墨菲定律”,也就是如果担心某件事情会发生,那么它往往会变得更糟糕,工作中可能的情形就是我们对某处代码可能一直新村疑虑,没彻底捋清楚其中的逻辑,心存疑虑但并没付出行动去攻克它,项目上往往就容易在这块出问题。
我的习惯就是对于自己负责的模块,不管是自己全新开发还是接盘别的同事代码,一定需要从头到尾把代码逻辑梳理清楚,时间充分的话画出对应的流程图,对不熟悉的代码看懂看透。
case4 重视测试环节
开发中,很多同事觉得会写代码才是王道,轻视了测试在整个开发环节的分量,很多问题其实只需要简单测试下就能检查出来,但由于不测试或者测试不充分导致问题报出防线后移,或者直接流到客户端,市场。
我们需要养成重视测试的好习惯,针对我们能想到的case,可能的情形充分测试,降低出错的风险,这样即使后面爆出了问题,至少是我们knowhow不够,而不是我们能避免但自己没测试导致。
加油,每一个为梦想奋斗的人。