太惨了，凌晨4 点替别人修复bug……差点翻车，前两个月某天凌晨，上线以后，有同事观测到他所负责模块的监控曲线有异常！监

差点翻车

前两个月的某天凌晨，我司全新的一个营销工具，在全国如期上线。然而整个发布过程并非一帆风顺，在线上环境全量发布后，有同事观测到他所负责模块的监控曲线有异常！监控曲线在发布的时刻近乎于直线下跌。

经过初步排查，故障影响是：一部分新用户无法使用营销优惠~ 影响面非常大，所幸在凌晨的业务低峰期，实际影响有限，但是需要快速修复！不然等天亮用户请求量上来了，故障影响和定级就更大了！

目前接近凌晨4 点，时间很紧张！虽然这部分内容并非我负责，但我是当天的现场值班人，必须上！肝！

屎海无涯

我喝了一口红牛，打开电脑就扎进了陌生代码的汪洋大海中……

看着看着，我察觉到味道不对劲。我觉得这部分代码不是汪洋大海，而是一片屎海…… 代码堆砌如屎山，单个方法竟超过500行；嵌套的if else结构深不可测；日志更是完全缺失；职责不但不单一，反而极度混乱。总之，整个代码简直如同一团乱麻，排查难度极大。

四五个同事一起在排查代码，虽然他们负责过这部分代码，但是大家都十分挠头，找不到 bug 在哪。

当局者迷，旁观者清。经过了30分钟的细致分析，终于，我率先找到了 bug 原因。激动地心颤抖的手，我开了 5 分钟的 bug 发布会，通报了 bug 根因和修复方案。

破案了！

确定 bug 根因后，其他人默默去休息了……

接下来我负责修 bug、测试、打包、发版、验证…… 不知不觉，天空破晓，一直搞到早上 8 点多…… 在线上完成验证，监控曲线恢复正常！bug 修复完成！

bug根因

由于公司代码保密，所以我使用伪代码解释。

业务逻辑是遍历所有的优惠活动，若任意一个优惠活动需要限制新用户使用，那么就需要去查询当前用户是否新用户。

bug 代码如下！（实际的屎山代码，比这部分代码要复杂得多！）

boolean newUserCheckEnabled = false;
for ( Activity activity : activityList ) {
     newUserCheckEnabled = activity.isLimitNewUser();
}

想必大家一眼就能看出问题所在！这样写代码， newUserCheckEnabled 等于最后一个活动的值，如果最后一个活动不限制新用户使用，那么 newUserCheckEnabled 就是 false，然而中间的活动可能需要限制新用户，于是 bug 产生了！

老板亲自指导写代码

正确的代码应该这样写，我按照如下方式修复了 bug，但是老板对代码不满意！

boolean newUserCheckEnabled = false;
for ( Activity activity : activityList ) {
     if (activity.isLimitNewUser()) {
         newUserCheckEnabled = true;
     }
}

”一行代码就能解决的事，不需要使用 if “ ，老板看完我的代码后，说道。

他给出的代码示例如下，使用 || 表达式

boolean newUserCheckEnabled = false;
for ( Activity activity : activityList ) {
     newUserCheckEnabled = newUserCheckEnabled || activity.isLimitNewUser();
}

if 代码被替换如下！

newUserCheckEnabled = newUserCheckEnabled || activity.isLimitNewUser();

"这能行吗”？我的大脑飞速运转…… 这两段代码等价吗？似乎等价，但不是十分确定……

老板面前，不能暴露自己没跟上节奏，否则暴露智商。

我假装立刻明白，于是吹了一句，“卧槽，牛逼，这样写确实更加简洁吖！👍🏻”。（大家觉得应该怎么拍马屁，更合适？）

私底下，我还在心里嘀咕，两者真的等价吗？

现在我可以肯定：确实是等价的！

我是五阳，关注我，追踪更多我在大厂的工作经历和大型翻车现场。

【线上故障复盘】RPC 线程池被打满，1024个线程居然不够用？

悲惨！刚入职没几天，无意间把数据库删了，很尴尬，原因很奇葩

别踩雷！mysql 加字段隐藏了4个巨大风险！这可能是目前最全面地分析