以毒攻毒式修 Bug,味儿太冲了

6 条回复
74 次浏览

免责声明:以下代码已脱敏处理,但那股子恶心味儿,依然很正。


上代码

这是一段授权登录的逻辑,越看越觉得离谱。
本来想继续复用,结果越看越看不懂,最后只好重新写了一版,旧版本直接放弃治疗。下面是我简化后的老代码,味儿依然很浓

味道保持原汁原味,发出来让大家一起闻

复制
def funca():
    if 条件 A:
        if 条件 B:
            【代码 A】
            return ''
        
        【代码 B】
        return ''

    if not 条件 B:
        if guest:
            return ''
        else:
            if 条件 A: # ← 你在看什么?
                【代码 B】
                return ''
            【代码 C】
            return ''

    【代码 A】
    return ''

历史来源(最骚的部分)

重点来看 if not 条件 B 里面的这段:

复制
if not 条件 B:
    if guest:
        return ''
    else:

        # 现在版本
        -------------------------
        if 条件 A:
            【代码 B】
            return ''
        【代码 C】
        return ''
        -------------------------

        # 之前版本
        -------------------------
        【代码 B】
        【代码 C】
        return ''
        -------------------------

修 Bug 的精髓在这里

以前的版本里,【代码 B】和【代码 C】是紧挨着一起执行的,结果出了 Bug(具体什么 Bug 已经没人记得了)。
新版本的修复方式非常优雅
在【代码 B】前面加了一个 if 条件 A。
而这个条件 A 在这辈子、在这条路径下永远都不可能为真。
于是【代码 B】被成功“永久禁用”,Bug 自然就没了。
代码没删,逻辑没改,历史包袱也没扔,就这么用一个永远走不到的死分支,把前人的 Bug 轻轻盖住了。

总结一下个人的感受

这代码已经不是逻辑复杂了,这是逻辑自闭+条件永真/永假的艺术

种子用户

即使你简化了逻辑,我依旧看不懂

复制
def funca():
    if 条件 A:
        if 条件 B:
            【代码 A】
            return ''
 中间省略...
    【代码 A】
    return ''

我不明白(蒋介石口音)
既然最终都要执行代码 A,前面搞俩 if 的目的是什么

都听我说!
OP

问的好

偷懒吧,最上面那个条件 A 代码是同时提交的,估计想着新的功能打复制一份打个补丁就完事了

虽然这个补丁很明显就是有问题的,不理解

再次补丁 bug 就成现在那个样子了fake_sad

马上来

我修过一个 bug, 往上拉一个百八十行的 sql, 我复制出来吭哧吭哧啃了一下午, 往下一拉发现他用另一个 sql 重新给这个变量赋值了

发表一个评论

R保持