记录工作中的生产事故

单元测试不规范

由于最近项目比较紧，由以前的两周为一迭代发布版本，改为一周发布版本一次。基本是周一早上澄清Story，然后开发的时间周期为周三之前必须提供Story给到测试，测试需要两天时间验证，周五上生产。这种情况下，容易出现些小问题，但是可能到线上就是大问题。就是这两天，我为解决生产线上的一个小问题，但是直接在业务代码流程中写死数据进行单元测试，也是自己考虑不周到，给自己埋下大坑。当自己写死数据在业务流程中，测试完发现不是自己的问题，然后发现是第三方供应商问题，然后让他修改了，就没注意自己在业务流程中留下的代码，不经意就提交到git,然后上生产，测试也没有时间去全量测试，就把这个小问题到生产了。其实，到生产之后，客户用之后发现问题，我们去定位问题也是很快的，但是这个确实是自己的马虎，偷懒，应该正规的在单元测试用例中验证，不能在业务代码中留下这个代码。

解决生产问题引发连锁效应

对于这个问题，作为开发人员很多人都知道，在解决一个问题的同时，一不小心就可能会留下其他问题。这个需要开发人员有一个很好的开发习惯，比如，自己的业务流程中方法的行数不能太长，越长的代码，越容易引出问题。在几百行中的一个方法中，你去修改了其中的一个问题，说不定一不小心就会遗留一个空指针或者其他的问题，所以能把自己的业务代码，简单逻辑，不要在一堆代码中去查找。养成好的编码习惯，至少给自己留下的BUG少，当然，对于每一个变量建议做多些判断，为kong的判断，不然测试在环境中可能会出现脏数据，然后发现代码总是报错。当然，不同的人在线上还会遇到不同问题。