编者按：软件越来越庞大，日益蚕食世界。但是在计算硬件指数性发展了几十年的时间里，软件的开发方式却基本保持不变。随着软件变得越来越庞大，对关键系统的渗透越来越深入，软件正在积累着越来越高的风险，我们如何才能排除那些看不见的定时炸弹，避免软件给世界带来末日呢？《大西洋月刊》的一篇长文对此进行了分析。本文较长，请保持耐心。

　　2014年4月10日晚上，整个华盛顿州的911服务断了6个小时。打电话求助的人听到的都是忙音。当一个陌生人试图闯入自己家时一位西雅图的女性至少拨打了37次911都没打通。后来那人从窗户爬进了客厅，她拿起了一把菜刀那人才逃走了。

　　那次911服务中断是当时有报道最大的一次，原因后来被追查到科罗拉多Englewood市一台服务器的软件上。该服务器由系统提供商Intrado运营，上面保存了一个计数器，记录的是路由给全美911调度员的呼叫数。Intrado的程序员给这个计数器设置了一个阈值上限。他们选择的数字是100万。

　　4月10日午夜过后不久，该计算器就超过了这个数字从而引发混乱。因为这个计数器是用来给每个电话生成唯一标识的，所以新的来电都被拒绝了。同时由于这些程序员并没有预计到会出现这样的问题，他们并没有设置告警来唤起注意。没人知道发生了什么事情。服务着1100万的美国人的华盛顿州、加州、佛罗里达州、卡罗莱纳州以及明尼苏达州的调度中心，努力想要弄清楚呼叫者收到忙音究竟是怎么回事。结果直到早上他们才意识到罪魁祸首是Intrado的软件，而补救措施只需要改变一个数字。

　　不久前紧急呼叫还是在当地处理的。这样的话中断也是小规模的，而且容易诊断和修复。手机的崛起以及新能力带来的希望——比如发短信给911或者发视频给调度员等——推动着依赖于互联网的更复杂系统的开发。结果就是有史以来第一次出现了全国性的911中断。现在这么多年来已经出现过4次了。

　　有个说法是软件正在“蚕食世界”。一度由机械或者人工控制的关键系统越来越依赖于代码。也许没有比2015年的那个夏天更清楚表明这一点的案例了，因为离港系统出了问题，联合航空公司的飞机停飞；纽约证交所在系统升级后交易被挂起；华尔街日报网站的首页崩溃；西雅图的911系统再次宕机，这次是因为另一个路由器出了问题。这么多软件同时失效让人一度以为这是一次联合的网络攻击。但更令人感到害怕的是随后大家才意识到这些都是巧合。

　　研究软件安全达35年的MIT航空工程教授Nancy Leveson说：“我们做机电系统的时候往往会想尽一切办法去进行测试。”因为软件错误导致6位病人死亡的放疗机器Therac-25的报告就是她做的。“我们往往会考虑设备能够做的所有事情，会进入的所有状态。”比方说，控制铁路平交道列车运动的几点联锁的配置就那么多，几页纸就能把整个系统描述清楚，而且你可以把每种配置都实际跑一遍来看看会发生什么。一旦做好测试好之后，你就可以清楚知道在处置的是什么。

　　软件就不同了。只需编辑文件里面某处的文字，同一块硅晶就可以变成自动驾驶仪或者库存管理系统。这种灵活性既是软件的奇迹，也是它的诅咒。因为可以廉价地改变，所以软件总是在变；同时因为它跟现实的一切都是脱钩的——所以占据相同空间的程序可以比另一个复杂上千遍——软件往往会不受束缚地发展下去。Leveson写道：“问题在于我们在尝试建立超过自己管理能力范畴的系统。”

　　关于工程失败我们标准的思维框架是在二战后不久形成的（在软件出现之前，针对机电系统）。其想法是通过把部件做得可靠（比如引擎可承受40000次起飞与降落周期）以及为那些部件故障做好预案（准备2个引擎）来把东西做得可靠。但软件不会坏掉。Intrado的错误阈值不像导致飞机失事的缺损铆钉。软件完全是按照人的吩咐行事的。实际上软件执行得非常完美。它失败的原因在于它被告诉做了错误的事。软件失败是理解的失败以及想象的失败。Intrado其实是有个备份的路由器的，如果能自动切换过去的线服务。但“当时发生的情况是应用逻辑并没有要执行自动修正行动。”

　　现在正在进行的改变软件制作方式的尝试似乎都始于同一个前提：代码实在是太难琢磨了。那么在试图理解这些尝试之前，弄清楚为什么会这样是值得的：是什么让代码对大脑那么陌生，跟之前的东西那么不一样呢？

　　技术进步往往会改变世界的样子——你可以看着道路铺设下去，你可以看到天际线的崛起。但在今天你很难说出什么东西进行着了再造，因为这些东西经常是由代码重构的。比方说，当你踩了汽车油门时，你不再直接控制任何东西；脚踏板与风门之间并没有机械连接。相反，你只是给软件提交了一条命令，给引擎补充多少空气是由后者决定的。汽车就是你可以坐进去的计算机。方向盘和踏板一样可以是键盘的按键。

　　跟一切其他东西一样，汽车也被计算化以促进新功能。当一个程序负责风门和刹车时，在你距离另一辆车太近时它可以放慢车速，或者控制燃油喷射来帮助你省油。当它控制转向器时，它可以在你开始漂移时保持在自己车道内，或者引导你进入停车区。没有代码你实现不了这些功能。你可以试试，没有代码的汽车就会变成庞大的、重达40000磅但无法移动的发条装置。

　　软件让我们做出了有史以来最复杂的机器。但是我们几乎都没注意到，因为所有的复杂性都被包裹进小小的芯片里面以及数百万行的代码之中。但仅仅因为我们看不见复杂性并不意味着它就没有了。

　　著名的荷兰计算机科学家Edsger Dijkstra在1988年曾经写到：“必须思考一个头脑此前从未面临过的概念层级。” Dijkstra把这当成一种警示。随着程序员热切地想要把软件植入到关键系统当中，软件日益成为建造世界的关键——Dijkstra认为他们已经高估了自己。

　　变成之所以如此困难是因为它需要你像计算机一样思考。在计算的早期这种陌生感会更加鲜明一点。当时的代码还是0、1的形式。跟这些枯燥数字打交道的程序员与其实际要解决的问题距离实在是太疏远了。你不可能看出他们是在计算火炮轨迹还是在模拟井字棋游戏。像Fortran、C这样的编程语言以及“集成开发环境”的引入尽管有所改变，但却掩盖了这种基本的异化——事实上程序员并不直接解决问题，而是把时间花在给机器编写指令上面。

　　MIT软件安全专家Leveson说：“问题在于软件工程师并不理解也不关心自己试图解决的问题。”原因在于他们太过埋头于让自己的代码可以工作了。她说：“软件工程师喜欢为编码错误提供各种工具。”她指的是IDE。“但软件出现的严重问题其实跟需求有关，跟编码错误无关。”比方说，当你写代码控制汽车的风门时，重要的是何时以及如何打开风门打开多大的规则。但这些系统已经变得太过复杂，任何人脑子里都记不住所有东西。Leveson说：“汽车的代码现在已经超过了1亿行，你无法预料所有的事情。”

　　2007年9月，Jean Bookout载上自己最好的朋友开着一项丰田凯美瑞正行驶在高速公路上，突然油门好像被卡住了一样。她抬脚松开油门，汽车并没有放缓；她试着踩刹车，但却似乎失去了动力。当她以50英里的时速转入匝道时她踩下了紧急刹车。车子划出了一道150英尺长的滑痕然后撞上路边的路堤。乘客在这次事故中死亡。Bookout一个月后才从医院中醒来。

　　这次事故是众多对丰田汽车所谓的突然加速诉讼案中的一起。丰田把事故原因归咎于垫布的糟糕设计、踏板的“粘性”以及司机错误身上，但局外人怀疑该负责的应该是软件瑕疵。美国国家公路交通安全管理局征召了NASA的软件专家来对丰田的代码进行严密的审核。在将近10个月后，NASA仍未发现软件是事故原因的证据——但同时他们也说自己无法证明软件不是。

　　后来有人终于在Bookout事故的诉讼过程中找到了其中令人信服的关联。原告方的鉴定证人Michael Barr有一个软件专家团队花了18个月的时间来研究丰田的代码，捡起了NASA丢下来的东西。Barr把他们发现的东西称为是“面条式代码（spaghetti code，多页嵌套的if语句与for循环，包含大量复制-粘贴的过程代码，且没有合适的分割）”。如果代码一项功能一项功能地堆积起来共生了很多年的话就会变成纠缠不清无法跟踪，跟不用说进行穷尽测试去追查缺陷了。

　　Barr的团队利用同款凯美瑞证明了其实车载计算机有超过1000万种方式导致突然加速事故。他们证明了只需一位的翻转（从0变成1或者从1变成0）就能让汽车失去控制。丰田的自动防故障代码不足以阻止这一点。Barr作证说：“你让软件看管软件。如果这个软件失灵了还是由同一套程序或者应用来挽救局面的话是难堪此任的，因为它已经失效了。”

　　Barr的证词为Bookout及其朋友的家庭争取到了300万美元的赔偿。据《纽约时报》，这是针对丰田的诉讼案中首起就电控节气门系统进行的审判，也是丰田首次被发现对突然加速事故负责的案子。后来丰田总共召回了超过900万辆汽车，赔付金额接近30亿美元才了结了相关争端。

　　软件将来还会面临更多的坏日子。我们今后要更擅长做软件就变得非常重要，因为如果不行的话，随着软件变得越来越复杂以及连接更紧密，随着软件控制了更多的关键功能——今后的日子会变得更加糟糕。

　　问题是程序员已经很难跟上自己的创造物。自从1980年代以来，程序员的工作方式以及使用的工具几乎都没什么变化。大家逐渐开始担心这种情况难以为继。微软的IDE工具Visual Studio首席软件开发者Chris Granger说：“即便是非常好的程序员对自己的系统理解起来也很困难。” Granger在微软的时候曾经安排过一次对Visual Studio的端到端研究。这是他唯一完成过的一次类似研究。他用了1个月的时间在单面镜背后观察大家是怎么写代码的。“这些人怎么用工具？如何思考？如何坐在计算机前，有没有碰鼠标？所有这一切都有教条但并没有经过经验测试。”

　　发现令人吃惊。他说：“Visual Studio是全世界最庞大的单一软件之一。它的代码超过了5500万行。我在研究中发现其中98%都是不相干的。也就是说大部分的代码都没有针对大家面临的根本问题。我的最大感受是基本上大家就是在脑子里玩计算机。”程序员就像棋手下盲棋一样——其思维精力都放在想象拼图在什么地方上了，以至于已经没有精力再去思考比赛本身。

　　John Resig在自己的学生身上也注意到同样的事情。Resig是著名的JavaScript（有一半网站都是JS编写的）程序员，也是在线教育网站可汗学院的技术领导。2012年初的时候，他一直在纠结于网站的计算机科学课程。为什么学编程就这么难呢？根本问题似乎在于代码太过抽象了。开发软件不像用冰棍棒造桥，你可以看清楚冰棍，可以触摸粘胶。要想“造”程序，你得敲字。当你想改变程序（无论是游戏、网站或者物理仿真）的行为时，你改变的其实是文字。所以程序写得好的学生是那些可以将代码在脑子里过一遍，像计算机一样思考，能跟踪每一次中间计算的人。Resig像Granger一样，开始猜测编程是不是就得这样。过去40年计算机每18个月就把能力翻番。为什么编程却一点都没改变？

　　这两个人同时在相同情况下思考同一个问题并不是偶然。两人都看了同一场演讲，那是计算机研究学者Bret Victor个软件工程学生准备的。演讲在2012年2月被放到网上之后火了，它做出了两个大胆的判断。第一是我们写软件的方式基本上已经坏掉了。其二是Victor知道该怎么修正。

　　Bret Victor不喜欢写代码。他说：“这听起来很怪异。当我想要做东西，尤其是想用软件做东西时，我得排除这种天生的厌恶感，因为纵的不是我想做的东西，我只是在文字编辑器写一堆的文字。”

　　40岁的Victor思维敏捷但为人害。