事后诸葛亮:如何写出没有bug的软件

网上对苹果iOS7操作系统中最新暴露出的一个严重安全漏洞的讨论读起来十分有趣。如果你还没有读过Alex Langley对此的分析,那现应该读一下,写的非常好。

附带说一下,是一个TLS v1.2 SSL连接问题上的bug,签名认证没有被检查,使伪造签名成为可能。原因是代码永久的直接跳到了方法的结尾处,没有实际检查哈希结果是否正确。

问题程序

是什么导致了这样一个弱者的bug?我四处看了一下,下面是网友们总结出的几个原因:

  • 用C语言很难写出正确无误的程序
  • 苹果公司的程序员不用心
  • 编码风格中允许忽略大括号
  • 苹果公司里没有正规的代码审查
  • 使用了goto语句
  • 使用了自动代码合并
  • 没有开启编译器对死代码的警告
  • 没有使用静态分析工具
  • 没有好好测试

所有的这些原因看起来都像是在这个bug的产生中扮演了一定的角色。但有一个主导原因吗?

对代码的差异对比给不了多少有用的信息,在631行上的这个bug看起来怎么产生的都有可能。也许是一次代码合并错误,也许是愚蠢的拷贝/粘贴造成。

事实上,你很难,或许不可能找到一个单一的为此bug负责的原因,那我们能有什么良方?很多人说是指代码上没有用花括号包围的原因。例如Zed说:

这就是帕金森瑣碎定理的一个很好的例子:花费大量时间讨论无关紧要的琐事。引起这个bug的根源不是缺少花括号。有没有花括号不会成为这个多余的goto的产生的原因。

为什么我们,程序员们,总是抱怨编码风格问题,但却不重视代码审查对程序正确性的决定作用呢?虽然不好的编码风格会隐藏程序bug,但并不是编码风格产生的问题。我们太重视代码布局视觉上的问题,却故意逃避正确性问题。如果更注重正确性,绝对不可能让这种关键代码中未经测试的情况下发布。

好的编码风格并不能防止大部分的bug的产生——尽管有点作用。简单的编程语言能够减少bug的产生。代码审查的作用更大。静态分析能让你避免大量的bug。

认真的测试可以捕捉并防止很多bug的产生。这就是为什么对于关键的软件,比如cryptography
library
,有100%的测试覆盖率。这种一眼就能看出来的bug绝对不会在这种软件里出现。

未经测试的加密代码是用来解密的代码。

所以说,抱怨花括号是愚蠢的做法。相反,在这种情况下花括号会让问题更难发现,花括号不是问题的根源,也不是问题的解决方案。大家找错了方向。

分享这篇文章:
[英文原文:Wrong Solutions ]

3 Responses to 事后诸葛亮:如何写出没有bug的软件

  1. sxl says:

    这标题取的~ 怎么会有没有bug的软件呢。 软件都是一直下修改 改进中不断健壮的

  2. pengx17 says:

    原文看起来有点矛盾:一直在否定代码风格(比如花括号)的不重要性,感觉更增加了正确代码风格的必要性;前文刚说到代码审核这段差异对比看不出bug所在,后面却又强调了代码审核决定性作用;然后作者的重点似乎在于完善的测试是大家都忽视的东西,但实际上这一点已经在上文网友讨论里出现过了。。

    还有个翻译错误,
    未经测试的加密代码是用来解密的代码。原文是
    Untested cryptography code is broken cryptography code.
    应翻译为,未经测试的加密代码即是坏掉的加密代码。

  3. jassor says:

    显然题主在逃避问题。
    就连阁下自己也承认,编程风格是会影响到bug的隐藏与否的。
    那么如果说好的编程风格可以避免bug的隐藏,为什么不这样做呢?
    你所说的代码审查,事实上,假如代码像粥一样,那么再牛逼的程序员也没有耐心去一一阅读——乃至于他们宁可重新写一个程序出来,也不愿意在既有的基础上做任何事。
    所以?
    这是一篇没有营养的文章。

发表评论

电子邮件地址不会被公开。 必填项已用*标注