[ 行业动态 ] 第9期 2009年9月
避免软件的“fail whale”
作者：Dave Rosenberg，有着近15年的技术和市场营销经验，曾就职于贝尔实验室。他是MuleSource的创始人，目前任职于HardWay。
技术的海洋已经越来越像Twitter的fail whale，对于Gmail failures这样的错误已经习惯并接受了（Gmail的免费Email邮箱服务器down机了，很多使用者在Twitter上抱怨）。有时候它们的基础设施（比如说路由器，交换机）崩溃了，这看起来就像软件出错了一样轻易的就被接受了。
Coverity是一家在开发周期内专注于软件的完整性和提倡早期静态分析的公司。Mark Donsky是Coverity公司的产品总监，对在Scan site上执行的开源项目摘取了一个最近的静态分析结果，即在代码行和缺陷数量之间有71.9%的相关性。当然，随着代码越来越多的被集成到产品上，人们发现这是一个普遍存在的，而不止是开源项目才有的问题。各种各样的测试，包静态分析等，这些工具和方法被不同的组织采用。
Mark Donsky从四个方面阐述了静态分析的例子：
软件规模变得更大更复杂：今天的代码比几年以前有了显著的变化，如果你把Windows NT 3.1和XP进行对比，将发现代码增长了10倍从4万行增至40万行。如果这还不够，那么用多线程应用程序来应对已有的可用多核处理程序，是不是更复杂了。
软件缺陷带来更高的成本和风险：或许是软件日益复杂的后果，自动化和权利比以前变的更关键。因此，当有缺陷的软件投入生产，将花费更多的资金来修正错误。最近NIST的调查表明，现场发现缺陷并修复所需要的费用是在开发阶段发现并修复的30倍。
软件普及增加了风险概率：今天，软件几乎渗透到所有的行业，从航空控制系统，陆地交通或者医疗设施都有。一个简单的软件缺陷能导致数以百万的资金损失。在任何时候，软件错误是导致机场大楼延迟，运输系统混乱和高级安全信息泄露的直接原因。
捷开发需要自动化：敏捷软件开发需要的自动化测试方法被纳入开发过程中。敏捷开发模式中，编码和测试是持续进行的，整个项目团队对软件的完整性负责。静态分析贯穿整个过程并给团队成员提供指导。