坠机真的无法避免吗？波音飞机软件出现BUG

最近被波音坠机事件刷屏，据说是印度开发的飞行控制软件出 bug 导致的，想请教一下老师，软件 bug 是无法避免的吗？应该如何减少软件 bug 带来的危害呢？

首先给一个简短的回答：

对于大型软件来说，bug 是无法避免的，但是有效的质量控制手段，可以大幅度降低其危害。

下面是详细的分析，预计阅读时间五分钟，不需要任何软件开发基础：

所谓软件的 bug，通俗来说就是由于需求、设计、开发、部署、运行环境、操作等原因，软件执行出错。

对于本次事件来说，我们还不知道究竟是不是飞行控制软件中的某个 bug 导致了多起坠机事件，但如果飞行控制软件存在 bug，理论上当然会影响到飞行安全。

记得我前公司的 CTO 曾经说过：程序员的工作就是让软件 「貌似正常」 地运行。

这句话道出了一个真理：完全正常运行的软件几乎是不存在的。因为随着软件规模的越来越大，软件的复杂性也越来越高，加上软件运行的环境复杂，包括且不仅限于操作系统自己的复杂性、系统补丁升级、其他软件特别是安全软件可能带来的冲突、无法预测的硬件故障等等。

这么复杂的 「大系统」，没有任何一个人能完全搞清楚、弄明白，因此想要事无巨细地设计清晰、开发出完美的系统，就是不可能的。

问：这么说起来我们以后就只能乘坐满是 bug 的飞机，

祈祷自己不会坠机了吗？

其实也不是，虽然说完全避免 bug 是不可能的，但是通过有效的软件质量控制来确保软件的可靠性，却是现代软件开发产业中常见且行之有效的方法。

说到解决 bug，大家第一反应都是：测试。

确实，软件发布前的测试，是发现并解决 bug 的重要手段，具体又可以分为单元测试、系统联调测试、用户需求确认测试等等，方法也很多，包括黑盒、白盒、人工测试、自动化测试等。

但仅仅通过测试是无法发现大部分 bug，也只能让软件外表看起来正常，遇到一些极端情况或者无法预想的环境时，测试的作用就很低了。

同时测试是开发完成后才能进行的，事后测试带来的修复成本也非常高，不仅会导致大量的重新开发，还会严重延迟软件的发布时间。

良好的软件质量控制手段贯穿软件设计开发部署实施运行的整个过程，通过不同阶段的培训、评审、验证、保障等手段，真的让软件尽可能 「正常」，将软件出现 bug 的概率、bug 被触发的概率、 bug 触发后的损失等等都控制在可以接受的范围，这是软件工程里非常重要的环节。

另外，信息安全漏洞也是一种特殊形态的 bug，也会带来大量的风险和损失，同样也可以通过软件工程、质量控制等手段来进行预防和修复。

本次事件涉及到印度的软件外包产业，其实对软件的质量影响更大的可能并不是所谓的 「印度国民性」，而是 「海外软件外包」 这种形式，对软件质量控制带来了巨大的挑战：开发人员身处异地、不同时区、语言不一定畅通、缺乏足够的业务理解、责权不一致等等都会对软件质量造成巨大的伤害。

本文来自「 Shotgun 」的主题，更多精彩内容请扫描下方二维码查看。