前言

中秋国庆双节至，旅行or回乡探亲基本是大家的选择，看看风景或陪陪家人确实是个难得的机会。不过我的这次假期选择了闭关，不探亲，不会友，利用这个假期重新调整总结一下，为2023最后的三个月再奋斗一把。

今天跟大家分享几个工作中的好习惯或者说是心态，虽然道理简单，但却很容易被忽略。

case1 不想当然

在工作中是不是经常会遇到这种情况：看着自己改的一段代码，想当然的以为改动量不大，自己在开发中考虑的已经非常充分了，认为没必要再去测试或全部测试，代码也不必找同事review，但往往问题就容易在这些地方出问题，而且出的问题恰恰就是被忽略了。

思考：工作中，我们可能会犯一些错误，但千万不要范这种误以为的错误，这种错误特别低级，深究起来也很难解释。

由于人天生的惰性，不愿意多付出多余的精力去干自以为没意义的事情，所以就需要我们不想当然，改了代码就要充分测试，复杂逻辑变动需要约同事去review。

case2 不为了解决问题而解决问题

在开发中，遇到Bug大家是不是有过这种先把问题解决了再说，导致解决了一个Bug又冒出一个新的Bug。比如一个DTC在上电1min中左右会报出来，但上电3min之后就正常了，这时候大家是直接给这个DTC加一个3min的延时诊断，还是说去探究下1min左右会报出来的根本原因，再根据根本原因去解决？

单就上述的case，很多同学肯定会选把根本原因查出来，但实际开发中由于节奏快，任务重，真正遇到的时候可能就不一定会选哪个了，针对这些类似问题我个人的工作习惯是：

情况1：对于时间紧的问题，且验证充分可临时解决的问题，先把问题初步隐藏掉，但初步交付后还是需要尽力去查找问题的根本原因，争取在下一次软件迭代周期将根本问题解决掉；

情况2：对于不太紧急的问题，一定需要查出根本原因，知其然也知其所以然。

case3 不留问题死角

不知道大家也没有听过“墨菲定律”，也就是如果担心某件事情会发生，那么它往往会变得更糟糕，工作中可能的情形就是我们对某处代码可能一直新村疑虑，没彻底捋清楚其中的逻辑，心存疑虑但并没付出行动去攻克它，项目上往往就容易在这块出问题。

我的习惯就是对于自己负责的模块，不管是自己全新开发还是接盘别的同事代码，一定需要从头到尾把代码逻辑梳理清楚，时间充分的话画出对应的流程图，对不熟悉的代码看懂看透。

case4 重视测试环节

开发中，很多同事觉得会写代码才是王道，轻视了测试在整个开发环节的分量，很多问题其实只需要简单测试下就能检查出来，但由于不测试或者测试不充分导致问题报出防线后移，或者直接流到客户端，市场。

我们需要养成重视测试的好习惯，针对我们能想到的case，可能的情形充分测试，降低出错的风险，这样即使后面爆出了问题，至少是我们knowhow不够，而不是我们能避免但自己没测试导致。

加油，每一个为梦想奋斗的人。