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

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

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

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

问题程序

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

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

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

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

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

很显然写这段Apple SSL C 代码的家伙没有读过我的C语言书:永远使用花括号!

— zedshaw (@zedshaw) February 23, 2014

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

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

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

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

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

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

原文链接:http://blog.existentialize.com/wrong-solutions.html

译文链接:http://www.vaikan.com/wrong-solutions/

责任编辑:陈四芳 来源: 外刊IT评论
相关推荐

2015-12-07 17:24:53

物联网物联网分析

2011-10-24 15:35:10

IT运维云梯49

2014-05-12 15:42:53

公安局IT运维管理

2020-05-19 15:00:26

Bug代码语言

2010-07-14 16:13:43

诸葛亮求职记

2020-04-29 10:10:45

网络安全自动驾驶漏洞

2015-01-16 09:55:52

云部署API管理云安全

2018-08-30 07:03:49

2018-08-16 10:28:56

云端数据应用

2012-08-29 16:08:12

2021-01-13 10:26:28

Paxos 分布式协议

2022-03-18 08:37:12

二分查找算法元素

2018-08-23 09:54:47

人工智能集成学习

2018-01-29 21:56:28

Bug程序程序员

2020-07-15 08:17:16

代码

2017-03-15 13:41:16

数据库SQL调试

2013-06-07 14:00:23

代码维护

2020-05-11 15:23:58

CQRS代码命令

2021-09-01 08:55:20

JavaScript代码开发

2016-11-25 13:50:15

React组件SFC
点赞
收藏

51CTO技术栈公众号