V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
James369
V2EX  ›  程序员

软件系统一旦出现 bug,绝大多数情况下是 需求混乱导致的。

  •  
  •   James369 · 111 天前 · 3705 次点击
    这是一个创建于 111 天前的主题,其中的信息可能已经有所发展或是发生改变。
    写了这么多年的软件,已经练就了一身铜墙铁壁,不吹牛的说,“我”写出来的代码基本没有什么 bug 。
    更确切的说是在软件层面很少出现什么 bug,为什么,主要还是得益于严密的思维,丰富的经验积累,比如:
    ~ 传入的参数控制好边界,非法值的判断。
    ~ 所有的异常情况考虑周全,捕获到位。
    ~ 严格按照接口规范处理。
    ~ 返回码 /错误码处理到位。
    ~ 不写花里胡哨 /晦涩难懂的代码。
    ~ 谨慎处理并发 /异步 /回调。
    ~ 注意对象的生命周期,引用释放。
    ~ 写完一个功能,立马自测一遍。
    ...
    这种防御式的编程模式,基本做到了滴水不漏。所以给出去的软件模块 99%都不会有问题。


    然而 bug 终究会产生,这个时候“我”发现,大部分的 bug 都源自需求的混乱不勘,功能的杂乱堆叠,业务的纠缠不清。
    所以,再强大的软件设计师,都会被不好的需求搞死。(比如考虑各种兼容性,比如强行让一只鱼飞上天)
    这也是为什么再牛逼的操作系统也是 bug 连绵,补丁不断,因为需求太复杂了。
    47 条回复    2021-08-13 09:41:28 +08:00
    James369
        1
    James369   111 天前
    我应该说出了很多程序员的心声,哈
    chendy
        3
    chendy   111 天前
    但是市面上少说一半程序员做不到楼主说的这些。。。
    masterclock
        4
    masterclock   111 天前
    - 传入的参数控制好边界,非法值的判断:
    第一个就无法认同:
    一个测试工程师走进一家酒吧……
    sadfQED2
        5
    sadfQED2   111 天前 via Android
    我每次都写了各种 case 的单元测试,我代码提交后 qa 还会 review 代码,然后 qa 会写各种情况的功能测试用例。

    然后,依旧经常出 bug,根本原因就是,屎山太大,总会出现各种根本意料不到的反人类情况
    jones2000
        6
    jones2000   111 天前
    上线以后 bug 多不多, 还是要看你的 test case 覆盖是否够, Code coverage 是否够了.
    IvanLi127
        7
    IvanLi127   111 天前
    @masterclock 测试工程师走进一家酒吧后点的东西不就是在测入参嘛?
    wsseo
        8
    wsseo   111 天前
    @chendy 一半太少了吧
    MiketsuSmasher
        9
    MiketsuSmasher   111 天前   ❤️ 1
    @IvanLi127 酒吧开业了,顾客点了一份炒饭——测试工程师压根没往这方面想过——然后酒吧炸了
    sutra
        10
    sutra   111 天前   ❤️ 1
    “我写的 bug 是过去的 /未来的 feature,但它却是现在的 bug 。”
    kkbblzq
        11
    kkbblzq   111 天前
    一颗钻石被丢上了屎山,很快它就被屎山淹没了。
    janxin
        12
    janxin   111 天前 via iPhone
    为什么是“我”而不是我
    imbushuo
        13
    imbushuo   111 天前   ❤️ 2
    实际上 Spec 写的不严谨,实现的人对 Spec 的理解有误差也会导致问题:Leslie Lamport 来我们这里做 tech talk 的时候提到过他发明 Paxos 的时候写了一份英文说明和一份数学证明,结果没人看后者,大家都看着前者实现;直到几年前 MSR 有个实习生提醒他原版英文说明里有一句话有歧义,理解错了那句话会导致实现有一个潜在的 bug,然后他们发现很多开源 Paxos 实现全部理解错了那句话,导致它们都有这个共有的 bug

    他举这个例子说明 Spec 要用 formal 的东西写,比如说用 TLA+ 描述软件的行为
    Rocketer
        14
    Rocketer   111 天前 via iPhone
    @MiketsuSmasher 酒吧点炒饭那个深有同感。

    我曾经写过一段代码,需要根据数据库类型做不同处理。当时我们只有 MySQL 和 MongoDB,所以我写的 if…else...

    结果一年以后有人在一个新模块中用了 Oracle,崩了……
    James369
        15
    James369   111 天前
    @janxin 因为有些夸大的成分,所以加了双引号
    jorneyr
        16
    jorneyr   111 天前
    我们小公司,去年产生了 6000 多个 Bug,大多数都是开发人员写出的 Bug 。
    xuanbg
        17
    xuanbg   111 天前
    我从来不会因为需求混乱造成 bug 。不吹牛地说,任何混乱的需求只要上我手,就不会混乱了。

    然鹅,经常会有一些因为复制粘贴后忘记修改造成的小问题。这种 bug 一般自测一轮就都排除掉了。所以最终交付的产品基本没有 bug 。
    xuanbg
        18
    xuanbg   111 天前
    @masterclock 是的,只靠严谨没用,只有抽象才能解决。管你几路来,我只一路去,就不会有一个测试工程师走进一家酒吧的各种问题发生了。
    Qseven
        19
    Qseven   111 天前   ❤️ 1
    当一个程序员有了足够的责任心和敬畏心,那么他写出的代码会少很多 BUG 。
    wipbssldo
        20
    wipbssldo   111 天前
    @Qseven 首先要有足够的时间
    jslang
        21
    jslang   111 天前
    测试的时候不是很到位
    jslang
        22
    jslang   111 天前
    或者没有经过测试
    JaguarJack
        23
    JaguarJack   111 天前
    没时间!!!
    raaaaaar
        24
    raaaaaar   111 天前 via Android
    首先要有意识,再有能力,最后还要有足够的时间。太过于理想化,很多时候只能说有这个意识就够了,慢慢迭代就好,不可能一劳永逸的。
    imnpc
        25
    imnpc   111 天前
    很多时间是没有足够的时间测试 忙的时候 只能先开发完功能 让客户配合测试
    kop1989
        26
    kop1989   111 天前
    与其说是需求太复杂,不如说是覆盖不住处理需求的成本。
    而且成本不能 100%覆盖需求,是软件工程的常态。

    所以我们能做的,就是尽量的高效利用成本。(这里的成本包括但不限于时间、人力、项目风险等等)
    所以必然程序中充满着面向效率的妥协。

    bug 也就因此产生。
    kop1989
        27
    kop1989   111 天前
    这就像是,造一个一千年不倒塌的房子不难,难在你要在有限的成本以内造。
    wolfie
        28
    wolfie   111 天前
    项目管理问题 高于 需求变更
    liuidetmks
        29
    liuidetmks   111 天前
    @Rocketer 哈哈,这个锅是不是甩到你头上了。老代码为新需求造成的 bug 负责
    chanchan
        30
    chanchan   111 天前
    需求混乱?经常整个工作过程都很混乱其实
    liuidetmks
        31
    liuidetmks   111 天前
    @kop1989 有些需求甚至在部分情况下是矛盾的。有时候为了节约时间 /偷懒,
    目前业务不会覆盖到的逻辑就忽略了,或者 加一个永远不会再看一眼的 TODO

    后期需求又有变动. gg
    User9901
        32
    User9901   111 天前
    甩锅 101
    好好看好好学,圈起来要考的
    wat4me
        33
    wat4me   111 天前
    需求太多,时间太少。
    wat4me
        34
    wat4me   111 天前
    @wat4me 你和代码必须有一个能准时跑。
    duhb
        35
    duhb   111 天前 via iPhone
    时间够怎样都行,最主要的是时间不够问题。
    jack778
        36
    jack778   111 天前
    技术层面避免 bug 相对简单,但是业务逻辑很多是有坑的,稍微理解不透彻就出 bug 了。你永远不知道你的用户会怎么使用你的系统。
    jack778
        37
    jack778   111 天前
    @masterclock 只要让我看到你的源码,我就有办法让你的边界防御失效
    desdouble
        38
    desdouble   111 天前
    talk is cheap, show me the code.
    clf
        39
    clf   111 天前
    还有就是对业务理解的偏差导致的。后端接口按业务逻辑实现了,前端以为按 UI 写好就行了,结果调接口的时候能给你整出一堆花活。
    sexyback
        40
    sexyback   111 天前
    刚参加工作没多久,因为公司的项目经常做实验,效果好了就规模化,有时候需求不能很明确,经常改动,现在真心理解楼主的话
    suotm
        41
    suotm   110 天前   ❤️ 1
    哈哈,这个我晓得,多和 Rust 的编译器斗争,然后去写脚本语言( JavaScript/Python).
    macha
        42
    macha   110 天前
    业务一旦复杂起来就很难全部覆盖到,所以有时候我都是先和所有人谈好我的代码能覆盖的场景,让大家一起 review 。
    只要把所有场景 cover 住了,至少出去的产品是符合设计预期的。

    所以有时候不是追求无 bug,而是追求产品是符合设计预期的。
    yuruizhe
        43
    yuruizhe   110 天前
    @Rocketer else 后面多个 if 就好了,可惜啊
    dinjufen
        44
    dinjufen   110 天前
    我也想写出逻辑缜密、bug 少的代码,无奈经常加班太疲惫。996 的情况下你还能写出好代码么?很多公司把技术看得并不重,很多人认为只要增加工作时间,功能就一定会做得更快更好。
    rekulas
        45
    rekulas   110 天前
    如果说第一条多花点时间还勉强可以做到
    第二条 "所有的异常情况考虑周全,捕获到位。"
    永远做不到,如果你做到了,那一定是系统不够复杂
    Myprajna
        46
    Myprajna   110 天前
    老板,来一份酒吧炒饭!
    lulu7
        47
    lulu7   110 天前
    佩服楼主的责任心,如果程序员都是你这样的,那项目的效率会提高很多吧。之前看过一个尽早崩溃的贴子,现在有点分不清到底是尽早崩溃,还是用防御性编程了。一个死掉的程序不是比一个瘫痪的程序造成的损失要小得多吗?所以在没有瘫痪时要用防御式编程吗?
    贴子: https://www.zentao.net/redirect-index-19377.html
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   4033 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 27ms · UTC 06:11 · PVG 14:11 · LAX 22:11 · JFK 01:11
    ♥ Do have faith in what you're doing.