太惨了，凌晨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(); "这能行吗”？ 我的大脑飞速运转…… 这两段代码等价吗？似乎等价，但不是十分确定…… 老板面前，不能暴露自己没跟上节奏，否则暴露智商。 我假装立刻明白，于是吹了一句，“卧槽，牛逼，这样写确实更加简洁吖！????”。（大家觉得应该怎么拍马屁，更合适？） 私底下，我还在心里嘀咕，两者真的等价吗？ 现在我可以肯定：确实是等价的！ 点击关注公众号，“技术干货”及时达！ 阅读原文