技术开发 频道

开发者应从Zune崩溃中吸取三个教训

  【IT168 评论】2008年的最后一天,数以千计的Zune用户发现,他们无法正常使用30GB版本Zune播放器。据微软表示,导致该故障的原因是,在Zune的固件代码中存在漏洞,未能正确的处理闰年问题。从该事件中,每一个软件开发者都应该吸取三个教训。

  微软高级项目经理斯科特•汉赛尔曼(Scott Hanselman)曾经为程序员们写了一篇非常好的技术分析文章,来介绍这类边界情况下编程的危险,而且很明显他不是唯一提醒人们注意这类漏洞的人。

  不过,该事件除了让我们知道在编程时不要犯此类错误外,还有三件重要的事情,值得开发者、软件质量保证(QA)专业人员和他们的管理者牢记。

  这是软件开发过程和质量保证(QA)测试的失败

  值得庆幸的是,这个问题的解决办法非常简单——只需等待一天即可自动恢复正常,但是对于微软来说,犯这种低级错误,无疑是一件尴尬的事情。

  记得曾经有一本书叫做《我们在微软如何测试软件(How We Test Software at Microsoft)》,我为该书的作者感到十分难过,他或许会因为这件事情而遭人耻笑。在微软的确有很多天才,他们都是了不起的人,其中有些人堪称最聪明的技术人才。但是无论如何,通过这次事件,却说明微软没有创造出一个质量至上的文化。

  实际上,这个问题本来是完全可以避免的。正如一个来自伦敦的Web开发者所言,“诸如闰年的跨年转换之类的边界情形,应该是必须要进行测试的情况之一,而且在设备上解决这类问题并不麻烦。”他表示,诸如此类的日期问题真的应该在测试的时候就被发现;任何一种代码审查都会发现这种无限循环的问题。那么,为什么这样的测试没有进行?或者为什么该漏洞没有被发现?

  我知道,有的时候厂商为了实现“按时上市销售”,会减少很多该做的工作。质量保证测试并不是其唯一的牺牲品。但是,这次微软Zune播放器的故障,任何基本的单元测试都能轻易发现它。

  每个人都有犯错的可能。但是软件工程学的目的就是在产品发布前,发现并修复它的错误。

  那么,让我们来反思一下,自己公司的软件开发过程是否能发现类似微软Zune固件程序漏洞的错误呢?

  没有以史为鉴 闭门造车

  如果这个漏洞非常隐蔽,我们或许可以对微软予以谅解。但是事实并非如此,这是一个标准的日期运算问题。自从大型机诞生以来,计算机行业就一直在关注这个问题,而且每一种可能的变化都已被进行分析和处理,对每一种语言都是如此,从汇编语言到COBOL到Python和Ruby。这并不是说我们以前没有碰到过日期运算的问题,但是时至今日还犯闰年错误,是否比较垃圾?

  没有任何借口可以为自己代码中出现日期运算问题而开脱,尤其对于类似闰年这种浅显直接的问题更是如此。毕竟,这与要求你编写一个日期程序使其在某个日期播放一段音乐有所不同。解决此类漏洞的代码已经存在,你需要做的只是对其进行重用而已。为什么还有开发者要闭门造车,再去自己“重新发明”一套自己的办法呢?

  那么再让我们进一步反思一下,你的开发团队中是否在发生这种“闭门造车”、进行重复劳动的现象呢?

  犯错程序员或许依然在计算机行业中

  在社交网站Linkedln上,我将Zune Z2k问题称为一个“重大的失误”,令我吃惊的时,好几个人回帖反驳了我的这个说法,他们认为,Zune“仅仅”是一个消费电子产品,24小时不能听音乐不会给用户的生活带来多大的影响。

  这个观点我不同意,我依然认为这是一个重大的失败,尤其是从长远的观点来看更是如此。我一直坚信,每一个人都应该一直尽自己最大的努力来做好自己的工作,这叫做“职业道德”。如果你接受了你的工作,你就有责任去做好它。当然,有的时候有些人和事会超出你的控制范围之外,使得做到这一点可能比较困难;但这并不是你降低你的职责的借口。虽然我们现在讨论的只是一个小小的MP3播放器,不过创造最好的产品就是其开发团队的工作。

  尽管在关键性方面,这个设备的确是无足轻重,不过对于微软的销售收入来说,Zune所占的比例却不是一点分量都没有。我确信微软不会认为Zune成功与否无关紧要,我敢打赌,微软甚至梦想有一天它的销量能够超越苹果的iPod。

  是的,我们或许应该感到庆幸的是,这个错误发生在一个MP3播放器上,而不是发生在一个发电厂或一个医疗设备上。需要提及的一点是,发生故障的Zune播放器是一款比较老的型号。编写这个错误代码的程序员可能已经不再从事这个工作,不过他应该还在编程领域,或许最近几年已经为微软或其它公司编写了更多的嵌入式系统程序。如果上个星期该程序员已经为一个发电厂或医疗器械编写了核心软件,那么你还会认为这个错误无关紧要吗?

  质量保证不仅仅适用于修复代码。它还可以修复有问题的应用程序开发过程。无论是质量保证部门没有对此加以重视,或没有被给予足够的资源,还是因为开发者没有对自己的代码承担起责任,将问题抛给质量保证部门,让他们来发现每一个问题,或者其它什么原因。正如一位读者所言,“这可能是一个开发问题或需求问题。但是最终归结起来,它是一个管理上的问题。”

  曾经有人说过,微软对软件行业最大和最危险的贡献是,它降低了用户期望值,很明显,在微软Zune播放器漏洞这件事情上,这句话无疑还是比较有道理的。

0
相关文章