故障是每个Dev几乎都不可能避免的情况,除非他是下面两种人之一:
- 天才
- 从来没有接手任何稍微复杂一点的系统开发
对于绝大部分Dev,上面的两种情况都不实际,所以基本故障这个东西是不可避免的。
那么,自己制造故障的几率能不能减少呢?我的答案是——能!
如何减少触碰故障的几率呢?至少有下面几种方式:
- 尽量别去碰老代码
- 自己写代码或者修改代码时,做到充分的测试
- 研究自己或别人之前出现的故障,透彻分析故障发生的原因和规避方案
这几点只是我想到的比较普通的几点,可能还有其他的方法(甚至更好的方法),这里不对其他方式进行挖掘了,目的只是想从上面的几个方式中找到最根本的一些特性。当然,即使是上面的几种方式,也是可以组合使用的,比如能同时做到1、2、3点,也许是遇见故障几率最小的一种方案。这里,我们只是单独分析每种方案的利弊。
1、尽量别去碰老代码
优点:明哲保身之举,如果真的能做到,那基本不会碰到因为影响老逻辑产生的故障
缺点:实施的可行性不高(很多时候不是你的业务需求能够绕开这个问题的,要么修改原有逻辑代码;要么copy原有逻辑代码出来,再做个适当修改);会给后续想优化或重构该处逻辑的人员留下更大的障碍和更大产生故障的几率或者说风险(因为你可能在原有的“代码泥团”中又多掺和了一块泥)。
2、自己写代码或者修改代码时,做到充分的测试
优点:养成良好的开发习惯;能不断提高自己写高质量代码以及重构代码的能力和水平
缺点:并不能完全规避故障;在没有遇到故障之前,其实一直对故障也没有清晰明确的认识(一个人一直不犯错也未必是件好事)
3、研究自己或别人之前出现的故障,透彻分析故障发生的原因和规避方案
优点:能从真实的案例中看到并学习到自己之前没有注意到或者根本不知道的问题;减少自己出现同样问题的几率。
缺点:同样不能完全规避故障。
这里我想说的是,其实,减小自己搞出故障的几率,提高自身的开发水平和能力才是王道!但这点是目的,是目标。要达到这个目的或者实现这个目标,上面提到2、3点就是比较好的途径和手段了。我想通过这些方式,是可以有效减少自己搞出故障的几率的。
OK,业务需求依然多变,老的系统逻辑依然复杂并且不能抛弃不管,这些也是故障无法完全规避客观原因之一。那么故障发生了又该咋办?
永远不要为了过去犯下的错误悔恨不已而停滞不前,覆水难收的道理大家都懂。上帝是公平的,所以他不给任何人重来一次的机会。所以故障发生之后的what if是没什么意义的。当然我说的不是不认真分析问题产生的原因。在最快速的解决这个问题之后,认真的分析问题的原因是非常必要的。
对于新人:故障其实一次让自己成长的绝佳的机会。亲身真正去体会一下线上系统出现问题是因为某些你可能不清楚或不知的东西造成的,你会清楚的发现和学习很多东西。
对于老人:故障是一个让你重新认识自己工作方式或流程的很好的警世钟(多数时候,如果完全按照正规的流程出发,故障是可以避免的),是一个让你搞清楚原来可能模棱两可的概念或问题的绝佳机会。
故障并不可怕,但他却是用“鲜血”换来的。所以不要轻易放过他,珍惜每一次故障,他除了带给我们令我们恼怒的故障分,但同时也带给我们学习问题并不断提高的机会。真正让自己成长,不放过每一次这样的机会。