引言

这篇是最近才有这个想法来写一下，我是java开发，所以内容可能并不适用于有些小伙伴，大家主要看思路即可。

背景

这个线上问题发生了不久，我在沸点也发过几次，其实当时发生问题的时候，我正在开发，是其他几位同事接到了这个反馈然后在紧急排查，但是实际上产生问题的代码在我这里，所以呢，他们由于不太熟悉，没有很快的在测试环境复现出来，导致排查问题时间较长，后来是通过我师傅去查看代码发现了这部分的问题，一看代码其实问题就很清楚了，然后同时定位到这块儿是我开发的。

事故现象

我简要给大家描述一下当时的一个现象，就是有一个列表，每一条数据都可以发起一个动作，用户可以针对某条数据配置一些参数，然后保存。后面可以发起动作的时候也可以再修改这个参数，但是呢，这个参数只是临时生效一次，后面参数仍然是开始配置好的。但是当用户发起动作修改参数的时候却发现：哎？为什么没生效？？所以就汇报了。

事故原因

其实按理来说，这种基本的流程自己开发的时候肯定是应该注意到的，但是我自己疏忽吧，首先对于这部分功能了解个大概，当时修改的时候也是想当然了，没有进行debug先调试下，看看参数如何传递，后面是怎么处理的，直接上手修改了。最低级的就是针对传进来的参数做了一个remove的操作。事后想想也真是活该了。

代码梳理

具体的代码比较多，我就给大家发一下伪代码吧，如下：

...
String var = ...(前端传递的)
Map varMap = var.parseMap();
if(x){
    varMap.put(xxx,new HashMap())
}
// 以下是我写的逻辑
while(varMap.hasnext())
    if(varMap.next().type != 'xxx'){
        iteration.remove();
    }
}
...

主要问题就出在了我对前端传递的参数做了修改，其实上面一段代码主要是验证一个功能，但是我因为没有看后面具体是怎么用的，只看到了原来有一行是varMap.put(xxx,new HashMap())，我就想这个参数既然都可以把key对应的value置空，说明是可以对其进行修改的，然后我就按照自己错误的想法一错到底了...后来重新梳理时才发现，虽然有置空的操作，但是是因为这个功能在生产本来就不该有那个类型的参数，所以要排除掉，不对逻辑产生影响。

总结

所以这次也是给我自己一个教训，不要想当然，针对每一个小的改动都应该慎之又慎！平常一般都会梳理下，这次不知道怎么，就只是看见了眼前的这一个小需求，忘记了整体的把控，以至于发生了严重的问题。

后话

针对这次问题，心里挺复杂的，因为以前也出过问题，但是因为及时发现，然后修改了也就没事了，这次呢，写的时候领导已经提醒，涉及到生产，加个开关吧，也就是通过数据库的变量来对我的这部分功能做控制。但是由于是生产环境，所以范围也就扩大了。

提醒

这次给我一个提醒，以后针对这种修改或优化已有功能的任务，需要慎之又慎！

• 查看要修改的方法被哪些地方调用，避免影响的范围较广，产生问题可能性扩大。如果有多个方法调用，尽量不在方法内部做修改。
• 梳理清楚上下文，避免修改某个数据，导致原有的逻辑受到影响。
• 针对写完的逻辑，要自己看好涉及到多少情况，尽量自测到位。因为测试也可能测试不到。

感谢

感谢你的耐心阅读，如果我的分享对你有所启发或帮助，就给个赞呗，很开心能帮到别人。